B端组件库怎么规划？先做高频组件还是一次性做全套

不少团队第一次做组件库，会列出按钮、输入框、弹窗、表格等几十个名字，然后一口气画全。几个月后真正被频繁使用的只有少数，剩下的状态不全、代码没有对应，维护成本反而增加。

组件库应从真实产品中长出来，而不是照着某个开源系统抄目录。先解决反复出现、容易不一致、开发成本高的场景，再逐步扩展。

01 先盘点产品，而不是先盘点组件网站

把现有页面按业务场景拆开：录入、查询、审核、配置、监控、协作、异常处理。统计哪些模式重复出现，哪些地方因为同一问题出现多种做法。

如果产品还很早，至少先梳理未来三个月确定会开发的流程。组件库不是一次性建设项目，早期最怕为了“完整”设计大量暂时用不到的能力。

02 优先级看频率、差异和成本

高频且差异大的组件最值得先统一，例如按钮、表单、表格、筛选、弹窗和状态反馈。低频但风险高的组件，如权限确认、批量操作和危险操作，也应提前定义。

一个简单的判断方法是同时评估使用频率、当前不一致程度、开发重复成本和出错风险。四项都高，就应该进入第一批。

组件库分阶段建议

03 状态完整比视觉精细更重要

一个输入框不只有默认和输入状态，还可能涉及悬停、聚焦、禁用、只读、错误、成功、加载和帮助说明。表格则有空数据、加载、失败、选择、固定列、溢出和权限差异。

如果设计文件只有理想状态，开发仍要临时决定大量细节，组件库无法真正减少沟通。第一批组件宁可少，也要把状态和行为写清。

04 设计组件与前端组件要共享语言

名称、属性和变体最好能对应。例如设计里的size、status、disabled与代码属性一致，避免设计师说“次级小按钮”，开发组件却叫secondary compact。

并非每个设计变体都必须成为代码API，但差异必须能解释。每次新增变体前，都要判断它是通用规则还是一次性业务例外。

05 业务组件不要过早抽象

审批卡、报价单、设备状态面板这类组件通常带有业务语义。只有在多个流程中稳定重复后，才适合沉淀为业务组件。过早抽象会把尚未成熟的业务规则锁死。

可以先把它们记录为“模式”或模板，观察两三个版本后再决定是否进入正式组件库。

06 用减少浪费衡量建设效果

可以跟踪重复设计时间、开发复用率、视觉问题数量、交付走查问题、组件覆盖率和版本迁移成本。覆盖率不是越高越好，强行把所有页面塞进组件会损害业务效率。

每个季度检查一次：哪些组件没人用、哪些业务重复出现、哪些变体正在失控。组件库需要删减和合并，而不只是不断增加。

常见问题

组件库和设计系统是同一回事吗？

不是。组件库是设计系统的一部分，设计系统还包括原则、设计令牌、内容规范、模式、治理和研发实现。

早期产品需要做组件库吗？

需要基础规则和高频组件，但不必一次做全套。优先保障当前核心流程一致和可复用。

可以直接使用Ant Design吗？

可以作为前端基础，但仍需结合业务流程、品牌、信息密度和可访问性制定使用规则，不能只换颜色。

组件由设计还是前端负责？

需要共同负责。设计定义体验与视觉规则，前端负责可实现性、API和质量，产品与业务方提供场景。

组件变更后旧页面怎么办？

应有版本和迁移策略。重大变更需要说明影响范围、替代方案和迁移优先级，不能让旧页面悄悄失控。