组件库样式产物策略要先定

做组件库时，大家往往更关注组件 API，却容易把样式产物策略放到最后处理。结果就是代码已经打好了，接入方才发现样式引入方式不统一，要么全量注入太重，要么按需使用又很别扭。

我觉得样式策略最好在组件库成型早期就定下来。到底是每个组件独立带样式、统一输出一个 CSS 文件，还是同时提供全量与按需两种方式，这些都不只是构建细节，而是使用方式的一部分。

如果策略不清楚，后面会连带影响很多事情：文档示例怎么写、Tree Shaking 能做到什么程度、宿主应用的样式覆盖成本有多高。很多接入问题并不是组件本身设计错了，而是样式交付方式没有和使用场景对齐。

我一般更看重两件事：接入方能不能快速知道该引哪份样式，以及样式覆盖是否留足扩展空间。只要这两点没有想清楚，组件库后面就会不断出现“能用但不顺手”的反馈。

样式产物不是附属品，它和组件 API 一样，都是组件库对外契约的一部分。

前端里的很多“体验问题”本质上都是边界问题

围绕「组件库样式产物策略要先定」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。