用途：指导在编写共享工具、在 DRY 与 WET 之间取舍、或重构既有代码时，何时应抽象、何时应保留重复。
核心原则：优先选择重复而非错误抽象，等待模式自然浮现后再抽象。过早抽象会产生难以理解、难以维护的代码，解开一个错误抽象的成本远高于修复重复。
三次规则：同一代码至少在 3 处出现后才考虑抽象，这样才有足够上下文区分真实模式与偶然相似。
适合抽象的情况：相同代码出现在 3 处以上；模式已稳定、需求清晰；抽象能简化理解；各用例行为完全相同而非仅结构相似。
不适合抽象的情况：代码仅出现 1 至 2 处；需求仍在演进；各用例需要不同行为；为适配差异而不得不加入参数或条件分支。
错误抽象的演化：开发者先抽取重复代码，随后为“几乎兼容”的新需求添加 options 参数，更多变体不断堆积，最终变成难以理解的面条式代码。
修复方法：把抽象重新内联回各调用方；删除每个调用方不需要的部分；接受临时重复以换取清晰；基于当前理解重新抽取真正合适的抽象。
抽象的隐性成本：代码复用带来无关模块间的意外耦合；单一事实来源带来遮蔽缺陷的多层间接；DRY 合规带来组织惯性导致重构困难。
外观模式：用于包裹复杂子系统并提供简单接口，但过度使用会变成错误抽象。例如 Typography 组件为覆盖各种 HTML 文本特性不断新增 as、weight、color 等属性，最终限制能力。适合用外观的场景包括隐藏复杂逻辑（如日期选择器的本地化、日历渲染、键盘导航、无障碍）、强制设计系统约束；不适合的场景包括包裹简单 HTML 元素、一次性样式需求、需求仍在演进、或学习者仍需掌握底层技术。
初级开发者测试：若初级开发者必须先学外观 API，再学底层技术，还要为边界情况扩展外观，则外观只增加摩擦而非价值。
参考文献：Sandi Metz《The Wrong Abstraction》、Dan Abramov《The Wet Codebase》、Kent C. Dodds《AHA Programming》。
限制：资料聚焦原则与示例，未提供安装命令、具体平台支持或版本要求。