这是一篇关于设计模式边界的复盘，而不是设计模式教程。感觉是很小众的错误。
前情是我没学过规则树和组合模式，在问ai时一步步陷入了认知错误。
在学习项目时，我围绕“规则树”和“组合模式”产生了长时间困惑。回头看，这种困惑并不是因为概念本身有多难，而是定义没有在一开始被钉死，导致后续推理全部建立在模糊前提之上。这篇文章记录我最终厘清的正确理解，以及这类误解为什么极其容易发生。
一、问题的起点：把“规则树”和“组合模式”划了等号
课程中“规则树”的设计是：每个规则是一个节点，节点之间通过条件连接，执行时根据规则结果走向不同分支；同时我问ai得知组合模式会把对象组织成树形/图/甚至是链式，这个组织让我误以为组合模式有了决策的功能，于是我有了危险的认知：规则树 ≈ 组合模式，后续所有困惑几乎都源自这个等式。
二、最核心的误导点：树 ≠ 组合模式的能力核心
误解的关键的是，“树”这个结构本身就带有“左右分支/选择路径”的直觉含义，很容易让人误以为：组合模式常用树表示，树天然有“选路”感，那组合模式也在做决策/选路？这是错误的。
三、先定死定义：组合模式到底是什么、不是什么
1️⃣ 组合模式的核心（原教旨） ：组合模式是结构型设计模式，解决的问题只有一个——把“单个对象”和“对象组合”统一对待，消除调用方对“叶子/非叶子”的if-else判断。在GoF原始定义中，child是组成部分，Composite的默认语义是对所有child执行相同操作，它只关注结构统一。
2️⃣ 组合模式不负责什么（重中之重） ：它不负责决策、不负责选路、不负责流程控制，也不负责“根据条件选择哪个child”。一句话定锚：组合模式是“组合”，不是“组织流程”。
四、规则树是什么？—— 另一个层级的问题
规则树不是设计模式，而是领域建模方案，核心解决“一个规则执行完后，下一步应该走哪条路径”的决策问题。一个完整的规则树，通常包含三类能力：规则树 = 组合思想（统一规则节点的结构）+ 决策语义（规则结果→边→下一个节点）+ 执行引擎（驱动整个流程）。这里要明确：组合模式只是规则树的“结构基础”，规则树的“选路能力”来自额外建模（边+引擎），两者绝不等价。
五、为什么“只用组合模式”一定会退化成if/else？
这是关键推论：如果只使用组合模式、不引入“边/决策语义”，却想实现“根据结果走不同分支”，最终必然会把if/else写进节点类里——主流程的if/else消失了，但只是被“搬家”，流程依然写死在代码中无法配置。这也印证了：“决策”从来不是组合模式的职责范围。
六、这节课真正“多走的那一步”是什么？
课程中引入节点（rule）、边（ruleLine）、决策引擎（DecisionTreeEngine），本质是把“选路逻辑”从代码中提升为“结构化数据”。这一步的意义的是，if/else不是被隐藏，而是被建模，流程从“写死在代码里”变成“可配置的结构”——而这，已经超出了组合模式本身的能力边界。
七、最终正确的认知总结（可长期复用）
✔ 组合模式：解决的是“结构统一问题”，而非“决策问题”。它只关心“这是叶子还是组合”，不关心“接下来走哪条路”。
✔ 规则树：是“基于规则结果进行选路的决策模型”，可以使用组合模式作为结构基础，但绝对不等于组合模式。
✔ 误解根源：我们常常用“结构形态”（像不像树）判断“模式能力”，但正确方式是：用“职责边界”判断，而非外形类比。
八、核心学习经验（本次最大收获）
讨论设计模式或架构时，必须第一时间定死定义和边界，否则推理会在模糊前提下“自洽”，但方向可能完全偏离。这次我走了很多弯路，根本原因不是概念难，而是一开始没问清：“这个东西，负责什么？不负责什么？”
九、最终定锚（结尾总结）
组合模式解决“怎么组合结构”，规则树解决“怎么做决策”。把两者划等号，是学习中最常见、也最隐蔽的误区之一。我犯了这种错误，却也因这份困惑，真正触碰到了设计模式的核心——不是记结构、套外形，而是守边界、明职责。而这，正是从“死记模式”到“活用模式”的关键一步。
