设计模式与反模式
§1摘要与结论
别名：design pattern、anti-pattern、设计模式、反模式、大泥球、Big Ball of Mud、可复用设计知识 | 英文：Design Patterns and Anti-Patterns | 类型：方法原则 / concept
§2局部关系图
§3原理 · 为什么
软件设计中反复出现相似的问题，若每次都从零推导，就会重复付出认知成本，且不同人给出互不一致的解法。设计模式把已被验证的解法抽象为可复用的描述，使设计知识可以跨项目传承，并让团队用同一套词汇精确沟通结构意图。模式不是可直接套用的成品，而是「在特定语境与作用力下，针对某类问题的通用解法」：它描述的是解的骨架与参与者之间的关系，而非具体代码。与模式相对，反模式记录了那些初看有效、实际却弊大于利的常见解法，并给出已被验证的替代路径；它之所以有价值，正是因为这类错误会反复出现，且往往在短期内显得合理。设计模式与反模式共同构成设计经验的坐标系：正例告诉团队「可以怎么做」，反例告诉团队「哪些看似合理的路会通向复杂度」。其中大泥球是最典型的高频反模式——缺乏可感知架构、靠临时拼接蔓延而成，常源于持续的业务压力与人员流动。
§4机制 · 如何运作
设计模式通常由语境、问题、作用力与解法四部分刻画：语境界定适用场景，问题说明要解决的矛盾，作用力描述相互牵制的约束（性能、可读性、变化方向等），解法给出参与者及其协作结构与后果。模式按目的分类，说明它们分别作用于对象创建、结构组织与行为协作；按作用力选择而不是按名字匹配，是模式应用的核心。反模式的识别则依赖症状：当系统反复出现特定坏味道、并且投入的补救总是反弹时，往往意味着背后有某个反模式在持续生成问题——例如职责任意堆叠、接口持续膨胀、修改总是波及大范围。识别之后应追溯生成该症状的结构性原因，而不是逐个修补表面现象。模式本身也会随实现退化：当它被过度应用或被误解时，其结构会积累新的坏味道，使最初的收益被维护成本抵消。因此模式与反模式构成一个动态谱系——同一个解法在错误的语境或过度的使用下，会从前例滑向反例。
§5工程 · 怎么落地
使用模式时先分析问题的作用力，再核对候选模式的语境是否吻合，最后检查其后果是否可接受；不要因为「看起来像某个模式」就直接套用，更不能为了用模式而制造问题。把模式当作起点与共同语言：它提示了需要平衡的约束，但具体解法应结合语言能力与团队习惯裁剪，简单的直接方案往往优于为模式而引入的间接层。对反模式建立巡诊机制：以坏味道为信号，定期审视系统中的结构性退化，识别生成问题的高频结构并集中处理，而非逐处打补丁。记录模式选择与放弃的理由，使后来者能理解哪些约束促成了当前结构。由于模式的需求有时来自语言或平台表达能力的不足，评估模式时应先问「这个抽象是问题本身需要的，还是工具限制造成的」；若能在更简单的层次表达，通常应优先选择更直接的方案。最后，模式不是免于腐化的护身符，即便采用经典模式，也需持续检查其结构是否随演化而退化。
§6权衡卡
设计模式的价值与风险同源：它用已命名的结构换取沟通效率与经验复用，但代价是引入额外的类型、间接层与约定，一旦语境不符或使用过度，就把简单问题复杂化。
反例之一是把模式当模板填空：看到相似结构就套用，结果系统充满不必要的抽象层，理解一条调用链需要在多个参与者之间跳转。
反例之二是把模式当作设计成熟度的标志，为追求「用了模式」而设计，与「未确认必需前不添加」的原则直接冲突。
反例之三是忽视模式的退化：经典模式在实现中会积累坏味道，若不加维护，其结构会从收益来源转为维护负担。
因此应以问题与作用力为中心选择解法，把模式视为讨论工具而非目标，并持续维护其结构，避免它从前例滑向反例。
- 还需要区分「反模式」与「不理想的权衡」：并非所有看似糟糕的结构都是反模式，有些是在特定约束下做出的合理折中，脱离语境贴标签会造成误判。
- 模式也不是唯一的设计知识形态，部分模式在表达力更强的语言中会自然消解，这说明模式的需求与工具能力相关。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8冲突 / 对比表
| 对照维度 | 设计模式与反模式 | 抽象泄漏 |
|---|---|---|
| 定位 / 依据层 | 设计模式与反模式 · Design Patterns and Anti-Patterns | 抽象泄漏 · Leaky Abstraction |
| 核心定义（原文） | 设计模式是对反复出现的设计问题所给的可复用解法模板，提供团队共同语言但不保证适用；反模式是初看合理却适得其反的常见解法，二者把设计经验的正反两面固化为可传承的知识。 | 所有非平凡抽象都会在不同程度上泄漏其底层实现：性能、故障与边界行为会穿透抽象边界，使用者被迫了解本应被隐藏的细节。 |
| 首条机制断言（原文） | 软件设计中反复出现相似的问题，若每次都从零推导，就会重复付出认知成本，且不同人给出互不一致的解法。 | 抽象以简化换取可控性，它把复杂的底层机制投影成一个更易使用的模型；但被隐藏的机制并未消失，只是在压力下重新显现。 |
| 对照关系 | 模式封装复杂度，抽象泄漏标明其边界（对照） | 同一条 对照 边的另一端 |
| 典型反例（原文） | 反例之一是把模式当模板填空：看到相似结构就套用，结果系统充满不必要的抽象层，理解一条调用链需要在多个参与者之间跳转。反例之二是把模式当作设计成熟度的标志，为追求「用了模式」而设计，与「未确认必需前不添加」的原则直接冲突。反例之三是忽视模式的退化：经典模式在实现中会积累坏味道，若不加维护，其结构会从收益来源转为维护负担。因此应以问题与作用力为中心选择解法，把模式视为讨论工具而非目标，并持续维护其结构，避免它从前例滑向反例。 | 常见的失败模式是层层封装的「抽象塔」：每一层都假设下层不会泄漏，于是一次底层抖动被放大成跨层故障，排查时反而要穿透全部层次。 |
| 处置要点（原文） | 使用模式时先分析问题的作用力，再核对候选模式的语境是否吻合，最后检查其后果是否可接受；不要因为「看起来像某个模式」就直接套用，更不能为了用模式而制造问题。 | 设计抽象时显式写下它的泄漏面与失效模式：它假设了什么、在什么条件下不再成立、使用者会遇到哪些可观测代价。 |
§9案例带
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
网申 v3 多模块解耦
一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。
网申 v2 深度重构
一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。
preset 通道耦合分析
对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
插件 DAG 两次级联升级
在同一知识库上继续两轮上游级联升级：处理数百次提交与包的增删，暴露「依赖声明不等于运行时引用」、分层须按最长路径深度、纯外部依赖边不得入主图等差分陷阱，并以全量门控校验收口。
dsh-manager 插件深度分析
以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。
Hermes 七层架构总览
对八千余文件的工业级 AI Agent 项目做七层架构总览逆向，揭示其「越用越聪明」的自进化闭环如何在层间传导的控制型架构案例。
Open Code Review 图谱
对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
§10信源与核验
核验结论：模式是对反复出现问题解的模板，须结合具体语境与作用力判断适用性；误用会引入不必要复杂度与额外间接层，且经典模式在实现中自身也会退化出坏味道 [VEN-016]
核验结论：经典原著列为 23 个模式；部分工程速查门户列为 22 个（省略 Interpreter 模式），引用时须区分来源口径 [BK-032]
§11原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 组合 | → ESS-H-05 | 深模块与浅模块 E-745 | 模式以稳定接口封装变化，呼应深模块 |
| 对照 | → ESS-H-04 | 抽象泄漏 E-746 | 模式封装复杂度，抽象泄漏标明其边界 |
| 前置依赖 | ← ESS-H-08 | SOLID 职责划分与替换性 E-743 | 职责划分与替换性判据是理解模式适用性的前提 |
| 细化 | → ESS-H-02 | 内聚与耦合 E-744 | 模式是被命名的内聚与解耦结构解法 |