组件库三好标准：从设计变量到token体系的工程落地指南

做了三年内部组件库，最让我沮丧的不是没人用，而是连我自己都不想用。每次新增一个按钮变体，要复制粘贴三份代码；每个主题换色，得全局搜索十六进制色值；文档里的示例组件和线上行为总是慢一个版本。后来和一位做设计系统很久的朋友复盘，他一句话点醒我：一个组件库让人不想用，不是因为缺功能，而是因为缺标准。从那以后，我所在的团队把所有需求都收敛到“好看、好用、好维护”这三个字上，整个搭建方式和推进节奏完全变了。

这篇文章就是要把这套“三好”标准从口号翻译成可执行的指标、步骤和工程约束。我会从设计变量怎么定、token体系怎么分层、组件API怎么收敛，讲到文档校验、发布节奏、贡献门槛这些容易被忽略的运营细节。无论你是前端开发、UI设计师，还是要从零搭建组件库的团队技术负责人，都可以照着这套思路落地，少走很多弯路。

1. “三好”标准不是口号：拆解出可直接执行的设计与工程指标

1.1 好看：从视觉评审到回归基线，把“美”变成可比对的基线

“好看”听起来最主观，但在组件库语境里，它必须变成一条可回归的基线，否则每次视觉走查都在吵感觉。我见过某团队把按钮圆角从4像素改成6像素，理由是“更现代”，结果两周后发现所有图表卡片都显得发圆，整体界面气质跑偏。要避免这个问题，得把美观拆成三层来做。

第一层是视觉基调，包括颜色、字阶、间距、圆角、阴影和动效节奏。这不是让设计同学提一版静态稿就结束，而是要让每一类视觉属性都落到变量里，并且定义“什么情况不能碰”。比如主色变量只允许主题层覆盖，任何业务组件都不允许直接写新的十六进制色值；像圆角这类属性给出一个半档体系，分别是2、4、8、12这样的小步进，不允许出现“5像素”这种中间值，否则很快会失控。

第二层是组件内部的视觉一致性。例如所有输入类组件在聚焦态都必须有同样的描边宽度和偏移量，所有弹层类组件的阴影层级必须从同一个变量继承。我们在实际执行中会把这类规则写成标注提示，放在文档的注意事项区块里。这一层的目的，是让不同开发者写出的组件在观感上像出自同一个人之手。

第三层是回归基线，也就是自动化截图对比。每个组件版本发布前，用同一组测试数据跑一遍截图，把新图与基线图做像素级对比，把差异阈值暴露在评审群里。凡是视觉差异超过指定值却没有备注原因的合并请求，一律要求说明理由。这样做之后，我们团队里“我觉得好看/我觉得丑”的争论明显变少，因为大家会被引导到“差异是什么、是否在变量体系内”这两个更具体的问题上。严格来说，基线截图不能完全替代设计师的眼睛，但它能把美感判断从无效争吵变成可讨论的工程问题。

1.2 好用：从调用文档到属性收敛，把“顺手”变成接口契约

“好用”的核心不是写了几十页文档，而是让使用组件的人能够在五分钟内写对第一段代码。我们在实际中发现，绝大多数组件库不好用的根源是属性设计太发散。以按钮组件为例，如果允许调用者传入任意颜色、任意圆角、任意图标位置、任意尺寸，那调用方代码就会变得没人敢删、没人敢改。

好用的关键，是把属性收敛成有限枚举。按钮的尺寸定义为紧凑、默认、宽松三档，颜色必须是主题色板里的语义token，状态由组件内部穷举，不允许外部自定义。这样一来，调用方的代码会变得非常统一，组件库升级时破坏面也小得多。为了让属性边界像契约一样清晰，我们在文档里必须明确标注每个属性的必填状态、默认值、可选范围和是否需要订阅主题。我还要求每个组件的示例代码必须保持“最小可用”状态，不夹带业务私有配置。

更实际的一步是写一个“顺手度”接入测试。每次迭代后，让一位不熟悉该组件的开发者按文档写一个基础用法，记录从打开文档到跑出正确效果的时间。如果某次超过一定分钟数，就说明文档或默认值有问题。这个方法成本极低，但没有几个团队会主动做，而它恰恰能反映出真实的接入体验。

1.3 好维护：从单点产出到演进机制，把“远期成本”变成规则

一个组件库单点做得好不难，难的是连续维护三年后还能保持稳定节奏。好维护的标准可以拆成三个可衡量的指标：改动影响面可预期、变更链路可追溯、长期腐化速度可控制。

改动影响面可预期，意味着每一个属性、样式变量、组件接口都有明确的所有者。颜色变量属于基础层，组件属性属于组件层，布局容器属于模式层，业务页面不属于组件库范畴。这样任何改动都知道要通知谁，不会出现“改了主色按钮没变”的悬案。

变更链路可追溯，意味着从设计决策到代码实现、从变更日志到版本发布，每一个环节都有记录。我们内部要求每个组件变更必须关联到一个变更原因，没有原因的变更一律走拒绝合并流程。这样做虽然有点繁琐，但在半年后复盘时会发现检索效率极高。

长期腐化速度可控制，意味着要有持续检查和垃圾清理的机制。组件库的死亡方式通常不是突然崩塌，而是被人不断“顺手加一个参数”，最终变成所有人都不认识的庞然大物。为此要设一条铁律：新增一个配置项前，先回答为什么不能拆成新组件，以及是否会破坏现有枚举边界。这两条回答不通过，就不允许合并。

所以，“三好”标准在我实际理解中，就是一条基线、一份契约、一套演进规则。后面所有落地工作，几乎都在围绕这三件事做工程化展开。

2. 从零搭建的第一步：设计变量、权限边界与目录结构

2.1 设计变量是地基：先定“哪些能变、哪些不能变”

很多人搭建组件库的第一件事是写按钮组件，我的建议正好相反：第一件事是把设计变量定下来，并且花足够多的时间讨论“变量可变范围”。这里的变量不只是颜色和字号，还包括间距标尺、断点、层级、圆角、动效时长和缓动函数。设计变量是组件库和视觉语言之间的翻译层，如果这层翻译得不好，后面每个组件都会各自解释设计规范。

设计变量至少可以分为四层来管理。第一层是原始的值，比如色板里的所有色阶，字号的所有档位，间距的所有档位。第二层是语义决策层，比如主背景、正文颜色、边框颜色、警示颜色、页面留白、段落间距，这一层才会被组件直接引用。第三层是载体层，比如卡片、按钮、输入框、弹窗各自对应的背景与边框组合。第四层是品牌主题层，例如区分明亮与暗黑模式，或不同产品线的品牌化覆盖。

这样分层的核心目的是控制影响范围。底层变量可以透明暴露，但业务组件和第三方主题包只能修改语义层和品牌主题层，不允许越过层级直接改原始色值。举例来说，某条业务线想换主题，他只需要提交一个基于语义token的覆盖包，而不需要改动任何一个组件。为了让这套体系不沦为空谈，还要配套写一个自动校验脚本，对组件代码做静态检查，一旦出现硬编码颜色或字号就直接报错。

2.2 权限边界：组件库与业务代码之间的第一道墙

组件库和业务代码的边界如果不清，整个结构迟早会腐化。我见过最典型的场景是：业务方很着急，直接在组件源码里改了样式，线上问题当时解决了，但组件库却变成了业务私有样式的大杂烩。

为此建议在物理目录和代码审查两个维度同时设边界。代码仓库或目录层面，组件库单独成包发布；业务项目只能通过包管理器引用成品产物，不允许直接修改组件库源码。组件库内部也要找专人维护，至少要指定一个主维护者和几个模块负责人，不能只有贡献者没有责任人。

代码审查层面，所有合入组件库的提交都必须经过指定的四位检查人：一个负责样式规范，一个负责组件接口设计，一个负责无障碍与边界状态，一个负责兼容性与性能。四人都通过才能合入。这套流程看起来繁琐，但对维护长期的组件库来说是必须的，它能直接把很多“看起来能用但后续要返工”的问题挡在门外。

在开放的思路上，还应鼓励业务团队提问题，但提问题的方式统一走需求模板，里面明确要求填写使用场景、现有API为何无法满足、能否用组合的方式实现。把“我就要加这个属性”变成“我遇到了这样一个诉求”，边界就会清晰很多。

2.3 目录结构与命名规则：让查找成本趋近于零

组件库的目录结构如果不统一，光找组件就会消耗大量时间。我的习惯是让目录直接映射组件分类体系，而不是映射团队组织架构。基础组件按类型划分到输入类、反馈类、导航类、展示类、布局类等目录下；业务组件再单独放一个目录，且内部按业务域拆分子文件夹。

命名规则要与设计稿中组件名的命名完全对齐。这里有一个从实际项目里总结出的规范，给每位组件作者参考：

• 组件名用所在分类加功能名的组合，比如表单输入框命名为输入类-基础输入框，反馈弹窗命名为反馈类-确认弹窗，不要出现同物多名。
• 样式类名与变量名遵循完整表达原则，比如状态名前缀要包含组件名，避免HTML里出现风格不一致的短横线命名。
• 文件命名、组件命名、测试命名、文档命名必须通过脚手架一次性生成，不允许手动新建再复制改名。

除文件级别外，目录内还应该放一个维护说明文件，写明“本模块由谁维护、哪些组件可扩展、哪些组件禁止改接口、已知遗留问题”。这个文件的存在感不高，但对新接手的开发者特别友好。找到组件只是成本的一部分，更贵的成本是花了一小时才搞明白“这个组件为什么不能改”。

3. 样式架构落地：token体系、主题化与断点收敛

3.1 token分层的具体实操：从基础token到组件token的递进关系

设计变量聊的是概念，token体系聊的是工程落地。我把token按用途分成三层：基础token、语义token、组件token。

基础token对应上面所说的原始值，比如色板上的第100号颜色值、8像素间距、4像素圆角。语义token对应含义，比如主背景、主文本颜色、边框颜色、危险色，它们本身不掺入具体组件。组件token则是最靠近代码的一层，它把组件内部各个部位的颜色、尺寸、状态映射到语义token上。

实际操作中，我会为组件库里每个组件单独维护一份token映射表。以按钮组件为例，表格里的每一行就是一条映射规则，需要清晰的字段来表达用途、层级和状态。

这样设计的最大好处是，做主题切换时不需要修改任何组件代码。我们为某条业务线做深色主题时，只是新增了一个语义token覆盖层，组件内部完全没有动过。另外，组件token层还起到了“限流”作用——当开发者在代码里想直接写某个硬编码颜色时，他必须先回答一个很尴尬的问题：这个颜色该挂在哪个语义token下面，又不能直接暴露原始色值给样式表。

为了保证这套规范不被绕过去，我强烈建议加上代码校验。我们用简单的静态检查脚本做了一层防线，查的是样式表里是否存在非token的十六进制色值、是否存在非白名单的字号或间距数值。规则本身不复杂，但在几个月后能拦住一大批“图省事”的提交。

3.2 主题化的最小可行方案：借助CSS变量做覆盖层

很多团队一上来就想做完整的多主题方案，结果被建主题文件的复杂度吓退。我的建议是先做最小可行方案，让主题化只靠CSS变量覆盖来完成。举个例子，基础层定义一批CSS变量，组件层所有颜色和尺寸都引用这些变量而不是写死，结构大致如下：

:root { --primary-color: #2277aa; --primary-hover-color: #1b5f8a; --surface-color: #ffffff; --text-color: #222222; --border-color: #dddddd; } .app-theme-dark { --primary-color: #4a9dd6; --primary-hover-color: #6bb2e4; --surface-color: #1e1e1e; --text-color: #eeeeee; --border-color: #444444; }

切换主题时，只需要在根节点上切换类名，或者在页面容器上设置数据属性，组件们就会自动继承新变量。这种方案的优点是侵入性极低、升级风险小，因为组件代码完全不需要感知主题的存在。对于初版组件库来说，这也已经能满足绝大多数产品的需要。

更复杂的主题需求，比如动态品牌换肤、多品牌并存、小程序端无法使用CSS变量等场景，可以放到组件库稳定后再升级。但即便如此，token映射表和语义层的价值也不会白费——因为无论什么实现方案，最终主题包本质上都是在做“语义token的值重定义”，只是承载方式不同而已。

3.3 断点与尺寸体系：用“档位思维”替代自由取值

尺寸体系包括间距、字号、圆角、阴影、行高、图标尺寸等。我强烈建议所有尺寸都使用档位，而不是随意取整数值。很多组件库最终观感混乱，往往不是某个组件画得不好，而是不同组件的间距、字阶、圆角来自不同年代的随意判断，拼在一起就显得很挤或很散。

以间距为例，可以定义四个档位：紧凑、默认、宽松、超宽松。按钮、输入框、卡片、弹窗统一从这四个档位里取，不允许组件自己额外定义像素值。字阶也类似，正文、标题、注释、辅助标签各按档位取，不允许出现“16.5px”这种边界外的值。

断点与栅格体系同样要收敛。很多团队喜欢每个页面自由设置断点，导致组件在不同屏幕宽度下的表现无法预测。我们采用的是四档断点：手机窄屏、平板竖屏、桌面常规、桌面宽屏。组件在断点间的行为要么是等比缩放，要么是显式切换布局模式，不允许出现“每个组件自己定一套中间值”的模糊地带。

尺寸档位的设计还要考虑极端场景。比如文本输入框在超大字号模式下是否撑破栅格，弹窗在全屏模式下是否还有合理的宽度上限，这一系列“极值规则”建议在组件开发时直接固化到代码里，而不是寄希望于使用者自觉。

4. 组件设计的分寸感：API收敛、状态穷举与扩展缝

4.1 props如果不是枚举，迟早变成各自为政

组件API设计是整个组件库最容易失控的环节。我见过太多组件库在一年后，按钮组件有几十个props，弹窗组件甚至有“是否显示左上角关闭按钮”这样的配置项。每一个配置项看似都解决了一个具体问题，累积在一起却让组件变得无人敢维护、无人敢升级。

我的原则是：凡是能用设计与逻辑穷举的选项，一律做成枚举，不要做成自由字符串或布尔值。以对齐方式为例，与其让调用方传入字符串命令，不如让它在预设的几种对齐选项中选择，并且渲染结果完全可预期。自由值会让你像走钢丝一样无法判断异常表现，枚举则把预期风险直接压缩在交互逻辑中。

接下来是另一个常见误区：把布尔值当成万能扩展点。核心建议是，能合并成枚举状态的布尔项就合并，因为多个布尔值的组合会让组件陷入无法预估的状态矩阵。例如“是否禁用”和“是否只读”虽然语义不同，但组合后的状态行为必须显式定义，而不是靠开发者的临时判断。组件API设计走到这一步，才算真正有了工程气质。

4.2 状态与交互的穷举表：交付前必须填完的表格

我坚持每个带有状态的组件都要在三套状态维度上做穷举：外观状态、交互状态、逻辑状态。外观状态包括默认、悬停、聚焦、按下、禁用、只读等；交互状态包括鼠标键盘触屏、读屏软件解释、动画开关等；逻辑状态包括加载中、空数据、出错、临界数据量等。这三个维度组合起来会产生一批容易被忽略的边界情况。

更好用的做法是把穷举结果做成一张状态矩阵表，放在每个组件的文档顶部。下面是一个表格片段，用来说明状态矩阵应该如何设计：

这张表的价值在于沟通成本极低。设计师、开发者、测试都可以在同一张表上对齐“什么状态该长什么样”，而不是各自猜测。我们曾经因为没做穷举表，导致某个输入框在只读且禁用状态下显示了两套互斥的样式，这种低级问题往往就来自状态组合没有被显式定义。

表格还应该连带变更影响记录。当某个状态被修改时，触发条件、视觉表现、键盘适配要一起更新，别只改颜色不改交互说明。组件库的维护工作很大一部分是在维护这张状态矩阵表。

4.3 组合优先于配置：避免打造“全能怪”组件

组件库里那些什么都能做的“全能怪”组件，初看很强大，细看很难维护。一个典型例子是“高级表单容器”：它既要做校验，又要做异步请求，又要做分步，还要做联动。短时间内确实满足了不少业务需求，但半年后再想优化局部流程，会发现完全无从下手，因为所有逻辑都纠缠在一起。

我的建议是，优先用组合的方式解决复杂场景。把复杂界面拆成基础组件加布局容器，由使用方按业务需要自由组合，而不是把所有能力塞进一个组件里。一个更合理的做法是：组件库负责提供可靠且样式统一的积木块，同时提供一套组合套路示例；业务方在示例基础上按需拼装，组件库则保持体积和复杂度可控。

判断一个能力到底该放进组件里还是留到业务侧，可以用两个标准：这个能力是否绝大多数场景都需要；这个能力是否能被独立复用。如果两个答案都是肯定的，才考虑进组件库；如果只是少数场景需要，就让它留在业务域，最多沉淀一份参考实现。这样组件库的演进速度会慢一点，但稳定性和信任度会持续增加。

5. 高效落地工具链：文档、校验、发布与设计稿同步

5.1 文档组件与状态矩阵：让文档不再是“贴代码”

很多组件库的文档写了等于白写，因为里面只有示例代码，没有决策依据和边界说明。我会在文档开头强制加入三个模块：用途与适用场景、不适用场景、接入示例。用途与场景让使用者快速判断这是不是他要找的组件；不适用场景能减少大量误用；接入示例则必须是可直接运行的完整代码片段。

为避免文档与代码脱节，我还会用“文档组件”来承载示例。文档组件放在组件库源码中，直接引用真实组件，而不是复制一份静态字符串。这样版本升级后，文档示例会自动同步最新行为。界面展示与真实代码保持一致，这看似简单，但大部分文档落后的原因就是忽略了这层映射关系。

文档里还需要写明组件之间的关联关系。例如“表单输入框”与“校验错误提示”之间的关系，或“弹窗”与“遮罩层”的层级关系。组件不是孤立的页面零件，如果把关联关系画清楚，使用者会更快理解这套组件库的设计意图，接入效率也会好很多。

5.2 半自动化的命名与token校验：把规范写进检查工具

只靠文档和评审来维持规范，执行成本太高。值得投入时间的，是半自动化的代码校验。校验脚本至少要覆盖三件事：命名是否规范、是否出现硬编码变量、是否存在过度配置的属性。

我给组件库跑过一次全校验，结果发现硬编码色值出现在近两成样式文件里。把这些硬编码全部替换成token后，后续做主题化时的改动量小了非常多。这类校验要放在提交检查的环节之前，或者至少在发布流程中作为必须通过的步骤。故意“绕过校验”的做法并不可取，但可以通过设置白名单和基线值来管理历史遗留问题。

命名校验也要做成脚本。组件名、样式前缀、测试文件、文档文件是否和脚手架生成一致，都可以让工具来检查。人脑应该去做设计决策，而不应该花时间去对命名大小写。

5.3 发布节奏、版本号与变更记录：稳定比高频更重要

组件库不同于业务应用，发布节奏应该稳定且收敛，不能每个需求都急着发版。我建议采用“固定周期发布+紧急修复通道”的双轨模式。固定周期内把待发布变更打包，跑完回归后统一发版。紧急修复通道仅限影响线上阻断问题使用，并在发布后及时补充完善变更记录。

版本号策略建议遵循规范格式，大版本对应破坏性变更，中版本对应新功能，小版本对应修复和内部优化。如果某个破坏性变更没有同步更新文档和迁移指引，就不允许发布。变更记录要写在仓库的重要文档里，按版本倒序排列，并注明每个变更的动机链接。

发布动作之后还有一个容易被忽视的操作：通知使用者。我们每次发布都会同步一份简短说明，列清楚哪些组件有新增、哪些行为有变化、哪些代码需要调整。日常沟通成本虽然不高，但能让整个团队对组件库保持实时信任。

5.4 设计稿与代码之间的同步：减少“设计改完，代码没跟上”

设计与代码脱节是组件库维护成本的大头。我们的做法是把设计稿中的组件命名与代码中的组件名严格对齐，并且把设计变量和代码token做映射。两者之间不能出现“设计里叫主按钮，代码里叫关键行动按钮”这类同物多名。

设计稿还要建立版本对应关系。每个组件库版本发布时，都对应一份设计稿基线版本。如果UI调整，得给出明确的版本号说明，代码只认这个基线版本，避免设计稿里同时存在新旧两套按钮样式。这样做的直接效果是，设计团队和开发团队讨论问题时，能精确到“设计稿第几版和代码第几版不一致”，而不是泛泛地讲“按钮感觉不太对”。

考虑到很多团队没法做到完全同步，可以先从“设计变量与代码token的映射表”开始维护。映射表一开始可能是一份公开的在线表格，随着组件库成熟再固化成校验规则。同步的完整方案不是一次就能搭完的，但每一步都能降低未来维护成本。

6. 运营组件库的长期成本：评审清单、变更审批与贡献门槛

6.1 每周评审清单：用一张表挡住无意识的腐化

组件库不是搭完就结束的项目，它是一个持续运营的产品。我建议每周或每个迭代做一次组件库评审，评审不必太长，但清单要固定：

• 本周是否有组件被新增了配置项？如果是，有没有回答“为什么不能拆成新组件”。
• 是否有样式文件出现硬编码值？如果有，是否已接入token体系。
• 是否有组件文档与当前行为不一致？是否已更新到最新版本。
• 是否有测试用例因为规则变化而“顺手被注释”？是否有遗留问题登记。
• 设计变量的修改是否同步映射到基础token、语义token、组件token三层。

把这份清单固化成会议前必须填写的表单，评审效率会非常高。很多团队不做评审，是因为觉得组件库“没什么可聊的”，但一旦把上述问题摆上桌，几乎每次都有新发现。

从成本上看，最贵的不是写代码的时间，而是“已经写错但没人发现”的时间。每周花少量时间做宏观检查，远比半年后大重构便宜得多。

6.2 当引入成本的收益不高时，如何优雅拒绝

组件库维护到后期，最大的敌人往往不是技术难度，而是“不好意思拒绝”的需求。某团队曾希望在基础弹窗组件里增加一个仅单条业务线使用的头部插槽，理由很充分：临时需求很急。但如果答应了，弹窗组件就要为这个特例引入分支逻辑，后续所有使用者都要承担心智负担。

拒绝不等于一句话回绝。我会先把需求拆成两个选项：如果使用方愿意接受“弹窗作为通用组件只做通用场景，业务线上使用业务弹窗封装”的方案，可以更快落地；如果一定要改通用组件，则必须做全量回归、更新文档与状态矩阵、同时报废原有约定。通常情况下，让对方看到全量成本后，他自己就会选择更轻的方案。

组件库需要有明确的变更委员会。这里不需要复杂的架构组，只需要指定一至两位对组件库演进方向负责的维护者，让他们对“是否变更接口”有明确决定权。这个角色不一定权力越大越好，但一定要有稳定性和判断力。

6.3 贡献者入口：让外部团队愿意把价值交回沉淀

组件库只有少数几个人在维护，必然不可持续。要让多个业务团队的开发者愿意回传组件，就得把贡献门槛降到足够低，且让他们明确感受到贡献是对自己的好处。

第一步是让“提交贡献”变得简单：有贡献规范、有开发环境、有最小示例模板。很多开发者不愿意贡献，往往是因为弄不清本地开发环境怎么跑起来。把这些做好，贡献量通常能提升一个量级。

第二步是让贡献者获得正向反馈。这体现为提交记录里的署名、发布的更新日志里出现名字、以及在可能的团队分享中有展示机会。人被认可，才会愿意持续输出。

第三步是设置“组件实习生”机制。新加入的开发者可以从修文档、补测试用例开始，再逐步进入真实组件开发。这套机制不但能缓解维护者压力，还能让组件库的知识和标准越来越清晰地理清边界。回传的价值不只是一点点代码量，更是在帮组件库养一批理解设计语言的共建者。

7. 最后说几点真实的执行体会

组件库的搭建本质上是设计标准与工程约束互相咬合的过程。很多团队失败，不是某个组件写得不好，而是把组件库当成一次性输出物，上线以后就不再持续投入。我个人体感是，组件库前三周的节奏几乎决定了它半年的状态，如果前两周没有做完设计变量分层、目录规范、评审清单，后面再想起来补就会非常痛苦。

还有一个小技巧，创建组件库时最好把“变更日志”当成一等公民来维护。不要等到发布前再补，而是每合入一个变更就顺手更新。这会让发布日轻松很多，也让大家在讨论“要不要做这个改动”时更有依据。

另一个容易被忽视的点是，组件库的文档和示例不要追求“大而全”，而要追求“最少却够用”。一个组件页面如果超过阅读负担，使用者反而会失去耐心。把“适用场景”和“不适用场景”写清楚，往往比写一大段原理说明更管用。

我在实际使用中遇到的最后一点体会是，组件库设计者要敢做减法。少一个配置项、少一个组件、少一套主题，在短期看来可能损失一点灵活度，但在一年的时间尺度上，换来的是更高的稳定性和更低的使用成本。一个组件库最终能走多远，很多时候取决于它拒绝了多少不该进的东西。

如果你正打算搭建或重构组件库，我的建议是，先花时间把“三好”标准转化成你们团队自己的指标，再动手。指标可以是视觉基线截图、接入时长、变更影响面、配置项数量，但一定要有。没有指标的标准只是愿望，有指标的标准才是工程。