在动手之前先回答三个问题：组件库服务谁（业务线/产品/多端）、覆盖哪些界面层级（基础/模式/页面模板）、交付给谁（设计师/前端/外包/运营）。范围越清晰，后续命名、拆分和维护成本越低。
建议用“80/20”原则：优先覆盖 80% 的高频组件（按钮、输入框、弹窗、表格、导航、卡片），剩下 20% 的长尾先用规范约束，等业务稳定再沉淀。
命名是可复用的第一道门槛。推荐采用“组件名/变体/状态/尺寸”的结构，例如：Button / Primary / Hover / M。命名尽量英文（或中英文对照）并保持词性一致：名词做组件名（Button、Input），形容词做变体（Primary、Danger），动词描述交互（Loading、Disabled）。
层级建议三层：Foundation（颜色/字号/间距等 Token）→ Components（可组合的小部件）→ Patterns（业务常见组合，如筛选条、卡片列表）。这样新增需求时能判断应该改 Token、改组件，还是新增 Pattern。
拆分时优先把变化归为属性（Variants/Props），而不是复制多份组件。常见可变项：尺寸（S/M/L）、层级（Primary/Secondary/Tertiary）、语义（Success/Warning/Danger）、形状（圆角/直角）、内容（图标/文本/左右布局）。
反过来，结构尽量稳定：按钮的内边距、图标与文字间距、默认高度等，用约束锁住。结构稳定才能在全局替换时不“炸版”。
组件库最常见的问题是：demo 好看，但真实数据一上就溢出。建议每个组件都至少验证四类极端场景：超长文案、空数据、异常数据（很长的数字/邮箱/URL）、窄屏（移动端或侧栏）。
输入框要明确：是否允许换行、是否截断、是否显示清除按钮、错误提示占不占位。按钮要明确：最小宽度、是否允许两行、loading 时是否锁宽。
如果团队未来要做多主题（品牌色/暗色/节日皮肤），Token 是唯一可控的路径。建议最少覆盖：Color（文本/背景/边框/状态色）、Typography（字号/行高/字重）、Spacing（4/8/12/16…）、Radius、Shadow、Z-index。
命名建议语义化：Color.Text.Primary 比 Color.Gray.900 更好迁移；同时保留少量基础色板用于插画或数据可视化。
每次发布组件库版本，建议固定输出一份交付清单：
1）本次新增/变更/废弃的组件列表；2）对应的使用说明（适用场景 + 禁用场景）；3）关键参数（尺寸、间距、状态）；4）交互说明（hover/active/focus/disabled/loading）；5）对前端的实现建议（布局方式、截断规则、边界条件）；6）回归检查点（哪些页面需要复测）。
组件库不是一次性项目，而是持续产品。建议建立最小维护机制：按月或按迭代发布版本号（例如 1.3.0），并维护变更记录（Changelog）。每个组件至少有一个负责人（owner），避免“谁都能改、结果没人敢用”。
当某个组件需要破坏性调整时，先提供兼容期：保留旧组件一段时间，并给出迁移指南。这样团队会更愿意跟随组件库演进。
发布前快速过一遍：命名一致、变体齐全、状态齐全、极端文案不炸、对齐和间距遵循 Token、说明文档可读、封面/示例图清晰、变更记录已更新。
做到这些，你的组件库会越来越像“工具”，而不是“素材”。
