接了个后台改版，翻代码发现按钮有四种圆角、三种禁用色，全是从别处抄来的片段。问下来，之前每来一个人就顺手引一套组件库。

先把三类东西分开

一类是带完整样式的 UI 框架，组件齐全、风格定死，改起来要跟它的变量体系较劲。一类是只管交互不管样式的无头组件，结构和键盘行为给你，外观自己写。还有一类是原生自定义元素，什么框架都能用，但生态和文档参差不齐。

按项目类型选

  • 后台管理系统，跟着主框架的生态走，表单校验、弹窗、表格这些重复活能省掉。
  • 官网和活动页，用原子化样式加无头组件，外观自由度最高，打包也小。
  • 要嵌进别人页面的挂件，用自定义元素，避开样式和版本冲突。
  • 老项目只补几个组件，抄一份轻量实现就行，别为三个按钮引一整套。

样式冲突比功能缺失更烦

两套库都定义了按钮的基础样式，后加载的把前面的盖掉，结果是本地好看、上线错位。排查时看计算后的样式来源，比一行行读代码快。项目一开始就定好引入顺序和重置策略，能省掉后面无数次对齐。

还有主题变量。有的库用 CSS 变量，有的用 Sass 变量，有的靠脚本注入。要改主色，先确认改哪一层，改错了打包不生效，只能在控制台里一个个试。

体积也要按实际页面算。文档上写的通常是压缩后的核心包，实际项目里带上的图标、日期库、国际化文件往往是它的两三倍。上线前跑一次打包分析，看哪些模块被整包引入，比看文档可靠。

选之前看四件事

看最近三个月的提交记录，停更的库别碰。看样式覆盖成本，有没有暴露主题变量。看文档里有没有写清无障碍和键盘操作。看按需引入的支持程度，全量引入的库在移动端很吃亏。

我的判断很简单：团队已经有统一框架就别另起炉灶，新项目从零开始才值得挑一套。样式一致性出问题，八成是同时引了两套以上。