先别急着构建可复用组件
内容提要
文章主张不要急于抽象复用组件。作者以审批、修改、移动三种“项目操作”为例，说明表面相似的流程在失败处理、审计和需求上差异很大，强行合并会导致大量模式、标志和例外，修改需多方协调。建议同一原因重复三次再抽象；日期格式化等可复用，提交逻辑因归属不同应分开。过早抽象可通过内联回各调用点、按流程拆分再提取真正共性来恢复。
延伸解读
表面相似不等于可复用
文章以审批、修改、移动三种项目操作为例，指出它们界面相似但失败处理、审计需求和流程归属差异很大。强行合并后，组件需要大量模式、标志和例外来应对不同场景，任何改动都需多方协调。这提醒我们，复用决策不能只看代码外观，更要分析背后的业务逻辑和变更原因。
判断复用时机的实用标准
作者建议同一原因重复三次再抽象，并给出测试方法：问自己“如果需求变更，我会咨询谁？所有副本会同时改吗？”如果答案因副本而异，说明只是巧合而非真正重复。日期格式化因产品决策统一而适合提取，提交逻辑因归属不同应保持独立。这为开发者提供了可操作的判断依据。
哪些抽象值得从第一天开始
文章并非反对所有抽象，而是区分了值得共享的场景：稳定的基础组件（按钮、输入框）、设计令牌（颜色、间距）、无障碍行为（焦点管理、键盘导航）以及由标准驱动的功能（日期时间、货币格式化）。这些抽象的形状由外部标准或稳定需求决定，不易被未来屏幕设计扭曲，因此风险较低。
过早抽象后的恢复策略
如果已经创建了错误的抽象，作者建议先将公共模块内联回各调用点，删除该工作流不会走的分支，让每个副本简短易懂。然后按工作流而非布局拆分代码，待稳定后再提取真正因同一原因变化的共性部分。这种回退虽显倒退，但能恢复各流程的独立演进能力，避免协调成本。
Q&A
为什么不应该急着把相似界面抽象成可复用组件？
因为表面相似的流程可能在失败处理、审计要求和需求上差异很大，强行合并会导致大量模式、标志和例外，增加编码和协调成本，而且错误的抽象比重复代码更难撤销。
文章中的审批、修改、移动三个工作流有什么不同？
审批是对未来的断言（“我需要这个物品”），修改是即时发生的，移动需要另一个系统接受请求且可能被拒绝。它们在部分失败处理、审计信息和需求上各不相同。
强行合并三个工作流后导致了哪些问题？
组件逐渐增加了模式、变体、标志和特殊案例处理，每次新增屏幕或需求都要加标志或改共享行为，任何改动都需要三个流程所有者、审查者和测试用例的协调，引发争论。
什么时候应该开始抽象复用代码？
当同一原因导致的重复出现三次时再抽象。判断标准是：如果需求变化时你会咨询同一个人，并且所有副本会同时修改，那就是真正的重复；否则只是巧合。
哪些东西适合从一开始就复用？
稳定的基础组件（按钮、输入框、布局容器）、设计令牌（颜色、间距、字体尺度）、无障碍行为（焦点陷阱、键盘导航、标签）以及由标准驱动的内容（日期时间、货币格式化、协议客户端）。
如何判断一个抽象是否合理？
看 props 列表：如果描述的是渲染内容（children、size、tone），抽象可能合理；如果描述的是所处情境（mode、variant、isSpecial），则很可能把多个相似但不同的事物混在了一起。
如果已经做了过早的抽象，如何恢复？
先把公共模块内联回各调用点，复制代码并删除各流程不会走的分支；然后按流程而非布局拆分代码；等三个代码稳定后，再提取真正因同一原因而共用的部分。
