抽组件的判断标准
同一个模式在项目里出现三次以上，并且每次的差异都在可控范围内，才值得抽成组件。只出现一两次就抽，往往会在第三次使用时发现需求完全不同，结果组件里塞满条件分支，比不抽还难维护。
另一个判断依据是变化方式。如果各处使用时的差异集中在文案、图标、尺寸这几项，说明结构是稳定的，适合抽；如果差异在于内部布局或交互逻辑，说明它们其实是不同的东西，只是长得像，不该强行合并。
抽出来之后要能被替换。一个组件如果只有一种用法、不能换图标也不能换尺寸，它可能只是一个写死的页面片段，不必占用规范的位置。
变量先于组件
在抽组件之前，先统一颜色、间距、圆角、字号这些基础变量。没有变量约束，组件抽出来也会各处走样，最后变成若干个相似但不同源的实现。
变量按用途命名而不是按外观命名。主色、危险色、正文文字、次要文字这类语义命名，在换主题或调色时不用改各处引用；如果按蓝色、十四号命名，换主题时就得全局替换。变量表定期导出一份，设计工具和代码两侧保持一致，评审时就不会出现两边色值对不上的情况。
变量数量也需要克制。几十个颜色变量往往意味着没有真正统一，同一层级的元素用了多个近似的灰。间距变量最好成组给出，而不是随手取值。列表项、卡片、区块各自固定两三档间距，页面之间的节奏自然就统一了。改间距时只调变量，不用逐页去挪元素，也不容易出现差几个像素的错位。
命名规则一旦定下，就不要在后续使用中随意增加特例。特例一多，变量表就失去参考价值，没人会再照着查。
组件文档要写什么
文档的重点不是截图，而是使用边界。每个组件写清楚什么时候用、什么时候不要用、有哪些状态、可配置项有哪些。判断信息比外观信息更常被查阅。
把易错点写进文档。比如按钮在加载态下不可重复点击、标签数量超过五个时要折叠、空状态必须配操作入口。这些规则沉淀下来，新加入的人不必靠踩坑来学。
示例代码和真实用法保持一致。文档里的示例如果已经不是项目里的写法，就会误导后来者，维护成本反而更高。
例外怎么处理
规范不覆盖所有情况，重要的是给例外留出通道。项目里确实需要特殊处理时，允许跳出规范，但要记录原因和后续是否回归。没有通道，规范要么被无视，要么被无限扩张。
定期清理也很必要。使用率长期为零的组件、和别的组件高度重叠的组件、改过多次始终没人用的组件，都应该考虑合并或删除。沉淀的目的始终是让常见页面更快做出来，而不是让清单看起来更完整。
谁维护规范也要说清楚。没有明确的负责人，组件会逐渐被复制粘贴绕过，规范最后只剩一个名字，没人再参考里面的内容。
