开头
组合模式（Composite Pattern）大概是GoF这23个经典设计模式里“形式最统一、意图最简单”的一个——叶子节点和组合节点实现同一个接口，客户端对单个对象和树状结构一视同仁。标准写法在Java、C#里几乎不会走样，但放到C++里，情况就不一样了。C++有值语义、模板、RAII、多重继承、智能指针，同一套结构可以用五六种完全不同的姿势去搭，每一种对性能、类型安全、代码可维护性的影响都天差地别。这就是我理解的“C++中的组合模式变体”：不是安全地复述教科书，而是在C++这个具体生态环境下，重新审视并重构组合模式的实现形态。
这篇文章适合两类人。一类是刚学完设计模式、想在真实C++项目里落地的读者——你会发现教科书版本在C++里有一堆坑，从虚函数开销到生命周期设计都有讲究。另一类是维护老代码、见到各种“不像组合模式的组合模式”想搞清楚来龙去脉的读者——比如看到用std::variant硬造树结构，或看到Composite里塞了一堆std::function时不用困惑，这篇文章理清了它们的位置。文中所有场景均为模拟项目命名，不涉及任何真实业务。
1. 标准组合模式回顾：教科书方案在C++里为什么总觉得别扭
1.1 所谓标准实现，核心就三件事
先回顾最经典的组合模式结构。它通常由三个角色组成：抽象组件（Component）定义统一接口，叶子节点（Leaf）实现最基本的操作，组合节点（Composite）内部持有一组子节点并转发或聚合调用。客户端面对的是Component指针，它不需要关心自己拿到的到底是Leaf还是Composite——调用同一个接口方法，行为自动沿着树形结构展开。
用C++写出来大概是这个样子：
#include <memory> #include <vector> #include <string> #include <iostream> class Component { public: virtual ~Component() = default; virtual void operation() const = 0; virtual void add(std::unique_ptr<Component> child) { // 叶子节点默认不支持添加子节点 throw std::logic_error("leaf does not support add"); } virtual size_t childCount() const { return 0; } }; class Leaf : public Component { public: void operation() const override { std::cout << "Leaf operation\n"; } }; class Composite : public Component { public: void operation() const override { std::cout << "Composite begin\n"; for (const auto& child : children_) { child->operation(); } std::cout << "Composite end\n"; } void add(std::unique_ptr<Component> child) override { children_.push_back(std::move(child)); } size_t childCount() const override { return children_.size(); } private: std::vector<std::unique_ptr<Component>> children_; };这段代码本身逻辑没有任何问题，它能正确表达“部分-整体”关系，客户端持有基类指针就够了。但用C++标准审视它，会有几个隐性问题浮出水面。
1.2 教科书方案在C++里的四个酸痛处
第一个酸痛点是虚函数的性能代价。每个操作都要走一次vtable动态分发，在树很浅、节点很少时无所谓，一旦组合树体量大、操作频繁，虚调用的开销会被成倍放大。树形结构天然对缓存不友好，再叠加虚函数的分支跳转，数据热点散的场景下性能可能比静态分发的实现慢一个数量级。
第二个酸痛点是接口冗余。add和childCount放在基类里是教科书为了让“统一接口”成立而塞进去的，但叶子节点根本不支持add。虽然可以用抛异常兜底，可这个接口对Leaf而言就是凭空多出来的负担。更麻烦的是，任何调用方只要握着Component指针，就能尝试把子节点加到Leaf上——错误只能靠运行时发现，编译器帮不了你。
第三个酸痛点是生命周期管理。上面的代码我用std::unique_ptr管理子节点所有权，这已经比裸指针好太多。但真实项目里Composite对象往往还要被多个Observer同时访问，子树里又可能有反向指针指向父节点，这时unique_ptr就不够用了，得上shared_ptr，而shared_ptr一多，“循环引用”这个大坑立刻出现。教科书不会告诉你：树本身是天然的无环结构，但加上反向关联后，它就变成了一个图，引用计数就会被自己骗死。
第四个酸痛点是遍历方式单一。标准组合模式只有最简单的递归调用接口方法这一种遍历方式。但现实中的树形结构（表达式、菜单、权限树、文件系统）往往需要多种遍历：先序、后序、按层级、只遍历叶子、带深度信息的遍历。标准接口根本没法表达这些变化。
痛感越清晰，变体的价值就越明显。后面各个变体本质上都是在回答同一个问题：如何在保留组合模式“统一处理部分与整体”的核心语义的前提下，规避这四个痛点。
2. 变体一：用std::variant替代继承体系，把类型摊开来讲
2.1 为什么可以不用虚函数
C++17引入了std::variant，它把“一组类型中当前存储了哪一个”的判别逻辑交给编译期工具链去管理，而不是运行时通过vptr去跳。传统虚函数机制中，对象的真实类型信息由vptr隐式携带；而variant是把整个可选类型集合显式写出来，编译期就能精确知道有哪些分支。
对应到组合模式，我们可以定义一个节点类型，它要么是叶子，要么是组合节点，组合节点内部再嵌套持有同一组类型。这就是“组合模式变体”里最现代、最直接的一种形态。
写法如下：
#include <variant> #include <vector> #include <memory> #include <string> #include <iostream> struct LeafData { std::string name; }; struct CompositeNode; using Node = std::variant<LeafData, std::unique_ptr<CompositeNode>>; struct CompositeNode { std::vector<Node> children; }; class CompositeTree { public: void addLeaf(std::string name) { root_.children.push_back(LeafData{std::move(name)}); } CompositeNode& addComposite() { auto node = std::make_unique<CompositeNode>(); CompositeNode& ref = *node; root_.children.push_back(std::move(node)); return ref; } void traverse() const { visitNode(root_); } private: void visitNode(const Node& node) const { std::visit([this](const auto& arg) { using T = std::decay_t<decltype(arg)>; if constexpr (std::is_same_v<T, LeafData>) { std::cout << "Leaf: " << arg.name << "\n"; } else if constexpr (std::is_same_v<T, std::unique_ptr<CompositeNode>>) { std::cout << "Composite begin\n"; const auto& node = *arg; for (const auto& child : node.children) { visitNode(child); } std::cout << "Composite end\n"; } }, node); } CompositeNode root_; };注意这里的一个关键细节：Node这个variant不能直接持有CompositeNode类型，原因在于C++要求在声明variant时，其成员类型必须是完整类型，而一个递归结构直接包含自己会变成无限大的类型。解决方案就是包一层unique_ptr，让组合节点在variant里以指针形态存在，同时不破坏值语义的所有权关系。
这段代码有个非常漂亮的优势：不需要虚函数接口，不需要Component基类，不需要在Leaf上加add接口。类型是显式枚举出来的，std::visit内部用编译期派发访问当前类型，比起虚函数跳转往往能得到更好的内联机会。
2.2 std::visit分发的性能与类型安全
有读者会问：std::visit难道不是同样要做运行时判断吗？它内部确实需要根据当前variant的index来选调用哪个lambda实例，通常实现为一组跳转表。但区别在于，跳转表的分发只在进入std::visit时发生一次，而虚函数分发则发生在每一个接口方法上。如果遍历一棵大树的每个节点都调用一次std::visit，的确仍然有dispatch开销，但编译器常能基于调用模式做出更好的优化，并且代码被内联的概率远高于虚函数。
更重要的是类型安全。variant在构造时就保证存储类型一定在预设集合里，不可能出现Unknown类型。对于一个带错误处理的访问lambda，如果某个分支没有处理，编译期通过if constexpr条件直接剔除，不会产生运行时崩溃。
如果业务中存在大量“仅叶子参与”、“仅组合参与”的操作，variant实现不需要再写if (instanceof Leaf)之类危险的运行时判断，用std::visit + if constexpr就能静态完成分流。
2.3 什么时候不建议用这个变体
variant不是银弹。如果树结构需要在运行时动态加载新类型（比如插件机制），每次新增一种节点都要修改Node的variant定义并重新编译所有访问代码，这违背了开闭原则。标准组合模式的虚函数机制天生支持扩展新类而不改旧代码，variant显然做不到。另外，标准C++的std::variant是值语义存储在栈上还是堆上的细节也要想清楚，如果树节点数量非常大，每个variant的大小会按最大成员对齐，这比单独存一个基类指针内存占用更大。所以我的建议是：类型集合固定、性能敏感、希望编译器多帮忙优化的场景优先选variant；类型集合开放、需要插件化的场景老老实实回到虚函数。
3. 变体二：双分派结构——组合模式与访问者模式的组合拳
3.1 为什么要引入访问者
第二种值得实战借鉴的变体，是把组合模式和访问者模式（Visitor Pattern）绑定在一起实现。这么做最主要的原因是：标准组合模式只有“接口内置的操作”，但真实项目里对树的遍历操作五花八门——统计节点数、序列化为JSON、渲染成控件树、做权限校验、做表达式求值。如果把这些都塞进Component的接口里，每个新操作都要改动所有Node子类，类会发生膨胀且每一处变更都牵一发动全身。
如果把这些操作全部外置成Visitor，让每个节点提供accept接口，树的结构和操作就解耦了。Component只做一件事：让Visitor进来。真正的逻辑由Visitor在各节点类型上完成。
3.2 组合模式下的Visitor应该如何设计
这里先给出一段可直接落地的基础框架：
#include <memory> #include <vector> #include <iostream> #include <string> class Component; class Leaf; class Composite; class Visitor { public: virtual ~Visitor() = default; virtual void visitLeaf(Leaf& leaf) = 0; virtual void visitComposite(Composite& composite) = 0; }; class Component { public: virtual ~Component() = default; virtual void accept(Visitor& visitor) = 0; virtual std::unique_ptr<Component> clone() const = 0; }; class Leaf : public Component { public: std::string value; void accept(Visitor& visitor) override { visitor.visitLeaf(*this); } std::unique_ptr<Component> clone() const override { return std::make_unique<Leaf>(*this); } }; class Composite : public Component { public: std::vector<std::unique_ptr<Component>> children; void accept(Visitor& visitor) override { visitor.visitComposite(*this); } void add(std::unique_ptr<Component> child) { children.push_back(std::move(child)); } std::unique_ptr<Component> clone() const override { auto result = std::make_unique<Composite>(); for (const auto& child : children) { result->add(child->clone()); } return result; } };有了这个底座，任何一个树操作都只需要新增一个Visitor派生类，不需要再碰树节点本身。比如我想统计树中有多少个叶子节点：
#include <iostream> class LeafCountVisitor : public Visitor { public: size_t leafCount = 0; void visitLeaf(Leaf&) override { ++leafCount; } void visitComposite(Composite& composite) override { for (auto& child : composite.children) { child->accept(*this); } } };调用方只需要对根节点执行一次accept，整棵树就按预定的遍历策略被访问完毕。
3.3 双分派设计中的几个实操细节
这个变体有一个值得注意的点：visitComposite里要不要自动遍历子树？上面的LeafCountVisitor选择让Composite主动遍历子节点，好处是visitor可以自己决定是否深入以及按什么顺序深入。比如做一个“导出当前层JSON”的Visitor，就可以只访问当前Composite而不继续下钻，灵活性高很多。但如果每个Visitor都要写这段遍历代码，重复度也高，容易漏遍历。工程上我见过两条路：一是在Composite::accept内默认不遍历，遍历职责完全交给Visitor，逻辑最透明；二是提供一个BaseVisitor，把默认的深度优先遍历放在里面，具体Visitor只覆盖自己关心的节点类型。两条路各有利弊，我更推荐前者，因为默认全遍历掩盖了“某操作只想处理当前层”的意图，一旦默认行为和具体需求不一致反而更难排查。
const重载是第二个值得说的地方。上面的accept接口接收的是非const Visitor和Component，只覆盖了可变访问场景。如果需要对const树做只读分析（比如debug时打印树），就得再写一套const的accept和const Visitor接口，代码量几乎翻倍。很多团队偷懒不做，运行时用const_cast绕过去，一旦有人真的修改了树内容，调试起来极其痛苦。我的建议是别省这个事，一次性把const版本做完整。
3.4 与std::variant方案的横向对比
到这里，variation之间的选择就浮现出来了。点一下核心区别：
| 维度 | std::variant方案 | 访问者方案 |
|---|---|---|
| 新类型扩展 | 需要改variant定义并重新编译 | 新增类，改Visitor接口，旧类无需改动 |
| 新操作扩展 | 改访问lambda | 新增Visitor派生类，旧代码不需要动 |
| 默认遍历方式 | 手写递归，按需实现 | Visitor内定义访问逻辑 |
| 性能 | 编译期更利于内联 | 依赖accept的虚分发，两跳成本 |
| 类型安全 | 极强 | 一般，依赖基类指针的运行时类型安全 |
这个表格基本能帮助做取舍：类型优先开放扩展选访问者，操作优先多样化且类型集合稳定选variant，两种都是合理的组合模式变体，在不同语境下服务于同样的设计目标。
4. 变体三：函数式组合——用std::function与回调绕开类体系
4.1 从“节点是多态的类”到“节点是可调用的对象”
如果树的节点根本不承载复杂的业务数据，它传达的只是“子节点集合和一份执行逻辑”，那么组合模式完全可以用更轻的方式实现——用std::function保存每个节点的操作行为。这种做法在配置系统、路由表、菜单定义、规则引擎里相当常见。没有继承，没有虚函数，没有Visitor，节点就是一个std::function<void()>加上一个子节点列表。
来看一个具体例子。假设我们要搭建一个带撤销功能的命令树：
#include <functional> #include <memory> #include <vector> #include <iostream> #include <stack> class CommandNode { public: using Command = std::function<void()>; CommandNode(Command executeFn = nullptr) : executeFn_(std::move(executeFn)) {} void addChild(CommandNode child) { children_.push_back(std::move(child)); } void executeAll() const { for (const auto& child : children_) { child.executeAll(); } if (executeFn_) { executeFn_(); } } void executeLeafOnly() const { if (children_.empty() && executeFn_) { executeFn_(); } for (const auto& child : children_) { child.executeLeafOnly(); } } private: Command executeFn_; std::vector<CommandNode> children_; };这样的代码结构，本质上仍然符合组合模式的特征：叶子节点有executeFn_且没有子节点，组合节点只有子节点列表。调用不区分叶子还是组合，统一executeAll，就是“部分-整体一致对待”的落地。而这种形态写起来非常轻量——不需要额外定义一组类，读代码的人一眼就能看出树结构。
这段代码还有一个妙处：它把“如何遍历”也模式化成了方法。executeAll是后序先子后己，executeLeafOnly则跳过组合节点只执行叶子。如果需要更灵活的组合度，可以在CommandNode里再挂一个遍历器对象去替换这里的固定实现。
4.2 lambda捕获生命周期是最大的坑
函数式组合的威力在于可以捕获环境状态。比如一个菜单项点击后调用外部onClick方法，一个命令执行时锁定某个互斥量。但捕获状态的生命周期管理非常考验功底。看看这个经典踩坑代码：
class DataStore { public: void update(int delta) { std::cout << "update by " << delta << "\n"; } }; // 某处使用 void buildMenu(CommandNode& root) { auto store = std::make_shared<DataStore>(); CommandNode node([store] { store->update(42); }); root.addChild(std::move(node)); }这里我特意用shared_ptr捕获，而不是裸指针或引用。如果改成[this]或[&store]，一旦store对象在菜单节点存活期间被销毁，调用时就是未定义行为。树形结构往往存储期较长，尤其全局菜单、路由表这类根节点不会销毁，节点内捕获的对象却可能在模块卸载时先行释放，崩溃就会瞬间炸出来。踩过几次之后我的经验是：所有被树节点长生命周期持有的引用类型捕获统一用shared_ptr，从不裸指针，从不引用。
4.3 函数式组合的边界与扩展
函数式组合真正的短板是没有类型化节点数据。如果你想在每个节点上挂一个用户ID、一组权限标记或一个调试信息，std::function方案就得额外塞字段，而这些字段没有统一的类型约束，只能塞一个std::any进去，或者放任variant越滚越大。
解决这个问题的一种有效做法是：把函数式组合的节点职责拆开，节点本身仅维护属性数据，而操作函数通过外部关键值匹配查找。例如树节点可以保留一个字符串类型的type字段，发布时根据type去一个注册表里查对应的执行函数。这就是命令模式和组合模式的组合变体，在实际应用的规则引擎里非常实用。
5. 生命周期与性能：工程中的关键细节
5.1 shared_ptr循环引用：树和反向指针
前面每个变体都会涉及树节点之间的父子关系。最自然的安全写法是父持有子使用unique_ptr，但反向从子找父的需求也很常见。如果父子都用shared_ptr，树就变成了引用计数环，父节点持有子节点、子节点又持有父节点，计数永远减不到零，内存泄漏悄无声息。正确做法是父对子用shared_ptr，子对父用weak_ptr，其余扩展接口均通过weak_ptr的lock去获取临时所有权。
更稳妥的思路是避免子节点长期持有父节点——只在遍历过程中通过参数将父节点上下文传进来，用完后即释放。这种“上下文随遍历传递”的方式在树形结构里既清爽又安全。
5.2 遍历方式的工程选择：先序、后序与迭代器风格
组合模式的执行过程本质上依赖遍历。最常见的两种遍历，先序和后序，语义完全不同：计算表达式树的值，得先算完子节点才能得出当前节点结果，必须用后序；渲染一棵控件树，希望父控件先构建好再挂子控件，就得先序。工程上应该把遍历逻辑和节点数据分离出来，让它成为一个可选的策略对象。
如果树节点数量大、递归深度深，递归遍历可能爆栈，可以用显式栈来模拟递归。以variant方案为例，一个不用递归的深度优先遍历很容易实现：
#include <stack> void iterativeTraverse(const CompositeTree& tree) { std::stack<const Node*> st; st.push(&tree.root()); while (!st.empty()) { const Node* node = st.top(); st.pop(); std::visit([&st](const auto& arg) { using T = std::decay_t<decltype(arg)>; if constexpr (std::is_same_v<T, LeafData>) { std::cout << "Visit leaf: " << arg.name << "\n"; } else if constexpr (std::is_same_v<T, std::unique_ptr<CompositeNode>>) { std::cout << "Visit composite\n"; const auto& children = arg->children; for (auto it = children.rbegin(); it != children.rend(); ++it) { st.push(&(*it)); } } }, *node); } }这段代码不递归，适合深度极端的树。注意入栈顺序是反向的，保证弹出时是正向遍历。这是纯工程经验，教科书里很少会提到。
5.3 缓存友好性与批量构建
最后一个性能要点：如果组合树是一次性构建、反复遍历的，建树后的节点内存应该尽量连续。用shared_ptr或unique_ptr动态分配的节点散落在堆上，遍历时cache miss会非常严重。这时候可以考虑批量构建方案——树定义阶段收集所有节点到vector中，然后通过索引而非指针表达父子关系，相当于把树拍平成一个紧凑的池。这已经有点偏arena allocator的思路，但确实是真实项目里大规模组合结构性能优化的常用招数。虚拟文件系统、游戏场景树都有这么做的案例。
6. 常见问题与排查技巧实录
6.1 场景问题速查表
| 典型问题 | 可能的根因 | 排查方向 |
|---|---|---|
| 叶子节点被添加子节点但运行时才报错 | 接口设计把add放到了基类 | 尝试variant或把非通用操作从基类剥离 |
| 树销毁时程序崩溃/死锁 | shared_ptr循环引用，析构顺序依赖 | 用weak_ptr表达反向引用，或用unique_ptr持有子节点 |
| 遍历结果总是少一层或重复一层 | 先序/后序搞混，在父节点还没处理前就触达子节点 | 打印遍历轨迹，确认当前序符合语义 |
| 某些节点类型未触发访问 | 访问者方案的visitXXX方法签名不匹配或遍历分支写错 | 检查复合节点是否在visitComposite中遍历全部子节点 |
| variant存储的unique_ptr被拷贝导致编译错误 | variant要求拷贝构造，而unique_ptr不可拷贝 | 用std::unique_ptr成员时保留移动语义，或者用shared_ptr包裹 |
| lambda捕获指针悬空 | 捕获了栈对象或this指针，生命周期没管好 | 统一shared_ptr捕获，或者用全局注册表+索引 |
| 深度超过1000时栈溢出 | 递归遍历太深 | 切换迭代栈式遍历 |
6.2 一个实战排查案例
去年做一个模拟菜单权限系统时，遇到一个特别隐蔽的bug：菜单树渲染时在某个层级后菜单项全部消失，不是整体消失，而是从第八层开始完全空白。断点打了半天，发现是Composite::accept里遍历子children时，某几个子节点在上一轮动态增删中被销毁了，而children里还保留着悬空指针。当时用的是裸指针和递归遍历，排查困难到一度怀疑是渲染框架问题。后来把子节点改成unique_ptr持有，所有遍历过程中涉及交代的节点先用引用局部变量接管，问题立刻消失。这个案例的教训是：树形结构里任何“增删后遍历”的循环，都要先确认持有权没有在循环过程中悄悄转移。
6.3 调试树结构的通用技巧
开发时建议实现一个dumpVisitor或printNode工具，把树结构打印成缩进文本。每行显示节点类型和核心数据，并标注子节点数量。树出问题时先看前后端上下文的缩进结构是否符合预期，能节省大把定位时间。
动手写过几个组合模式变体之后，我自己总结出的经验是：先别着急选什么“正宗”写法，先想清楚两件事——你的节点类型集合会不会扩展，你的遍历操作会不会频繁变化。类型集合固化明显选variant，操作变化多端选访问者，两者混着选觉得不好定夺时，函数式组合往往是最灵活但最不容易出彩的中间路线。另一点是，无论选哪种变体，生命周期管理永远要放在第一位，裸指针会毁掉最漂亮的设计。这篇文章所涉及的项目场景均为模拟示意，希望你从这些变体里找到适合自己架构的那一支，用工程验证，而不是用教条验证。
