1. 从一段反复重写的代码说起说起来有点尴尬我第一次真正意识到访问者模式的价值是在一个图形编辑器项目里改需求改到想摔键盘的时候。那会儿系统里有一批形状类Circle、Rectangle、Line全部继承自一个抽象基类Shape。需求是给这批形状加一个导出为 JSON的功能当时图省事直接在每个子类里加了一个toJson()虚函数三下五除二搞定。结果过了两周产品又要加导出为 XML我又在每个类里加了一个toXml()。再后来是计算面积、碰撞检测、画到画布上……每来一个新操作我就得把Shape的所有子类挨个打开加一个虚函数。有一次甚至因为漏改了某个子类导致导出功能在特殊形状上直接崩溃。问题出在哪操作在变但对象结构很稳定。我想把操作和数据结构解耦让新增操作时不用再动那些已经稳定运行的类。也就是在那个节点我正式去翻了 GoF 那本书又开始认真使用 C 里的访问者模式Visitor Pattern。这篇文章我就围绕什么时候用访问者模式C 里怎么落地有哪些坑和替代方案三个问题把我这些年实际用下来的经验完整写一遍。适合已经掌握 C 面向对象基础、想在真实项目中把设计模式用起来的读者。2. 访问者模式到底在解决什么问题2.1 一个前提稳定的数据结构多变的行为访问者模式不是一个万金油模式它解决的问题域非常明确。用我自己的话概括当你的对象结构基本不变但需要不断在上面增加新的操作时访问者模式让你把新的操作从原对象中剥离出来做到新增操作只加代码、不改原类。这正好对应我上面图形编辑器的场景Circle、Rectangle这些类是稳定的但导出 JSON计算面积碰撞检测这些操作是频繁变化的。用访问者模式每来一个新操作就写一个新的 Visitor 类不用回头去动任何一个 Shape 子类。这背后其实是一种设计原则的取舍——开闭原则对扩展开放对修改关闭。传统的虚函数方案新增操作要修改所有子类是对修改开放而访问者模式通过双分派Double Dispatch把操作集中到独立的访问者类中实现了对扩展开放。2.2 和普通虚函数的本质区别双分派很多初学者会问我在基类定义一个纯虚函数doSomething()每个子类自己实现这不也一样吗不一样。普通虚函数是单分派运行时根据对象的实际类型调用该类型对应的虚函数。关键在于这个调用只取决于一个对象的类型。访问者模式要做到的是双分派最终执行哪个操作同时取决于被访问对象的类型和访问者的类型。用visitor-visit(circle)这行代码来说虽然表面上是调用Visitor::visit但实际运行的却是circle-accept(visitor)内部再反向调用的那个visitor-visitCircle(this)——两个对象类型共同决定了最终调用的函数。这里我放一段最经典的 C 实现后面整个章节都围绕它展开#include iostream #include vector #include memory // 前置声明 class Circle; class Rectangle; class Visitor; // 抽象节点稳定的数据结构 class Shape { public: virtual ~Shape() default; // accept 是双分派的入口 virtual void accept(Visitor v) 0; }; class Circle : public Shape { public: double radius 1.0; void accept(Visitor v) override { v.visitCircle(*this); // 关键把自己 this 传给访问者 } }; class Rectangle : public Shape { public: double width 1.0; double height 1.0; void accept(Visitor v) override { v.visitRectangle(*this); } }; // 抽象访问者每一种操作对应一个具体访问者 class Visitor { public: virtual ~Visitor() default; virtual void visitCircle(Circle c) 0; virtual void visitRectangle(Rectangle r) 0; };你看Shape体系只依赖一个核心方法accept(Visitor)每个子类只需要把自己的真实类型告诉访问者即可。这样后续新增操作只需要写class JsonExporter : public Visitor { public: void visitCircle(Circle c) override { std::cout { \type\: \circle\, \radius\: c.radius }\n; } void visitRectangle(Rectangle r) override { std::cout { \type\: \rectangle\, \width\: r.width , \height\: r.height }\n; } };一个全新的导出 JSON功能就完成了。Circle、Rectangle 的源代码一行都不用改。这就是这种模式最大的甜头。2.3 什么场景才真正划算我列一个我自己判断的实际应用清单供你对照节点类型稳定但操作频繁新增抽象语法树AST、表达式树、文件系统的节点、游戏中的实体对象。编译器里对 AST 做的类型检查、代码生成、格式化输出全是典型访问者应用。同一个对象结构需要执行多种不同且互不相关的算法比如商业引擎里对几何体做网格简化、碰撞体生成、包围盒计算每来一种新算法就写一个 Visitor。需要对对象结构进行复杂且非常规的遍历比如遍历一个对象图时要按访问者的内部状态决定是否继续深入或跳过某些节点。反过来如果对象结构本身也在频繁变化经常新增子类那就要极度谨慎。因为每增加一个节点类型所有已有的 Visitor 都必须同步增加一个visitNewType()这是一场灾难。这一点在后面常见问题里还会详细说。3. C 里实现访问者的核心细节3.1 为什么要双重分发从编译期到运行期理解双分派的关键在于理解 C 的函数重载决议发生在编译期而虚函数调用发生在运行期。看这段代码void doVisit(Visitor v, Shape s) { v.visit(s); // 编译期错误Visitor 没有 visit(Shape) 这个函数 }即使Shape的实际运行类型是Circle即使假设Visitor里重载了visit(Circle)C 编译器在编译这行代码时也只会按照静态类型Shape去查找匹配的visit重载。因为重载决议是静态的它不会在运行时根据s的真实类型去翻找对应的重载版本——虚函数机制只作用于成员函数本身不作用于重载参数。所以访问者模式绕了一个弯外部先调用s.accept(v)这里s是虚函数调用的触发者运行期分派到具体子类的accept在子类的accept内部this已经是精确类型Circle*再调用v.visitCircle(*this)*this的静态类型就是Circle重载决议精确命中。两步相加就是双分派第一步选择正确的节点方法第二步选择正确的访问者重载。3.2 virtual、const 与重载的正确姿势访问者实现里有几个细节特别容易踩坑我一个个说。第一accept的参数尽量用Visitor而不是Visitor。访问者是有状态、多态的传值会导致对象切割slicing所有子类特有数据全部丢失。第二visit系列函数要不要加const这取决于你的操作是否修改节点。我的建议是默认提供两套入口。实际操作里我发现计算面积这类只读操作和变换坐标这类写操作共存的情况很常见。class Visitor { public: virtual ~Visitor() default; // 只读访问 virtual void visitCircle(const Circle c) 0; // 可写访问 virtual void visitCircle(Circle c) 0; };在Circle::accept中可以根据自身状态选择调用哪一个class Circle : public Shape { public: double radius 1.0; void accept(Visitor v) override { v.visitCircle(*this); // 这里 *this 是 Circle优先匹配写版本 } void accept(Visitor v) const override { v.visitCircle(*this); // 这里 *this 是 const Circle匹配只读版本 } };第三重载与隐藏陷阱。如果某个Visitor子类只实现了visitCircle而忘了visitRectangle编译器不会报错——它只是在子类里把visitRectangle隐藏hide了。这是 C 不同于 Java 的一个大坑。解决办法有两个// 方法一基类里给纯虚函数提供默认空实现 class Visitor { public: virtual void visitCircle(Circle c) {} virtual void visitRectangle(Rectangle r) {} }; // 方法二子类里显式 using 基类重载 class JsonExporter : public Visitor { public: using Visitor::visitCircle; using Visitor::visitRectangle; void visitCircle(Circle c) override { /* ... */ } };我强烈建议采用方法一 静态断言的组合基类默认空实现 在关键visit函数里放static_assert检查防止平台期漏掉某个类。3.3 C 特有的内存与生命周期管理问题访问者模式在像 Java 这样带 GC 的语言里很舒服但在 C 里生命周期管理问题会主动找上门。一个常见场景你的Shape以std::shared_ptrShape存放在容器里访问者要遍历容器并访问每个元素。此时accept的签名最好设计成接收智能指针或者在遍历层保证裸指针的合法性。class Shape { public: virtual void accept(Visitor v) 0; // 如果访问者需要接收所有权可以增加一个重载 virtual void accept(std::shared_ptrVisitor v) { v-visitNode(*this); } };另一个坑Visitor 内部持有状态并且状态可能引用外部资源。比如一个收集所有圆形的 Visitor内部存了一个std::vectorCircle*。当 Visitor 作为局部对象传递时拷来拷去容易把内部指针搞悬空。我的实践是访问者对象禁止拷贝只在遍历函数内部以引用方式传递。class CollectCirclesVisitor : public Visitor { public: CollectCirclesVisitor() default; CollectCirclesVisitor(const CollectCirclesVisitor) delete; CollectCirclesVisitor operator(const CollectCirclesVisitor) delete; std::vectorCircle* circles; void visitCircle(Circle c) override { circles.push_back(c); } };4. 实战基于访问者模式实现图形序列化4.1 完整代码与核心操作步骤这一节我从零实现一个可运行的最小案例。场景一个画板里有圆形、矩形、线段三种图形需要导出为字符串、支持统计总周长并且后续可以低成本地新增导出为 XML。先定义节点结构#include iostream #include vector #include memory #include cmath #include string // 前置声明 class Circle; class Rectangle; class LineSegment; class Visitor; class Shape { public: virtual ~Shape() default; virtual void accept(Visitor v) 0; }; class Circle : public Shape { public: double cx 0.0, cy 0.0, radius 1.0; void accept(Visitor v) override { v.visitCircle(*this); } }; class Rectangle : public Shape { public: double x 0.0, y 0.0, width 1.0, height 1.0; void accept(Visitor v) override { v.visitRectangle(*this); } }; class LineSegment : public Shape { public: double x1 0.0, y1 0.0, x2 1.0, y2 1.0; void accept(Visitor v) override { v.visitLineSegment(*this); } };注意LineSegment是后来新增的节点类型——我故意加上它后面讲新增节点类型的代价时要用到。定义访问者接口class Visitor { public: virtual ~Visitor() default; virtual void visitCircle(Circle c) 0; virtual void visitRectangle(Rectangle r) 0; virtual void visitLineSegment(LineSegment l) 0; };定义第一个具体访问者负责文本序列化class TextExporter : public Visitor { public: std::string out; void visitCircle(Circle c) override { out Circle(center std::to_string(c.cx) , std::to_string(c.cy) , radius std::to_string(c.radius) )\n; } void visitRectangle(Rectangle r) override { out Rectangle( std::to_string(r.x) , std::to_string(r.y) , std::to_string(r.width) x std::to_string(r.height) )\n; } void visitLineSegment(LineSegment l) override { out Line( std::to_string(l.x1) , std::to_string(l.y1) - std::to_string(l.x2) , std::to_string(l.y2) )\n; } };定义第二个具体访问者负责总周长统计class PerimeterCalculator : public Visitor { public: double total 0.0; void visitCircle(Circle c) override { total 2.0 * M_PI * c.radius; } void visitRectangle(Rectangle r) override { total 2.0 * (r.width r.height); } void visitLineSegment(LineSegment l) override { double dx l.x2 - l.x1; double dy l.y2 - l.y1; total std::sqrt(dx * dx dy * dy); } };写一个遍历函数把容器里的元素依次交给访问者template typename Container, typename Visitor void traverse(Container shapes, Visitor v) { for (auto s : shapes) { s-accept(v); } }主函数演示int main() { std::vectorstd::unique_ptrShape shapes; shapes.push_back(std::make_uniqueCircle()); shapes.push_back(std::make_uniqueRectangle()); shapes.push_back(std::make_uniqueLineSegment()); TextExporter exporter; traverse(shapes, exporter); std::cout exporter.out; PerimeterCalculator calc; traverse(shapes, calc); std::cout Total perimeter: calc.total std::endl; return 0; }编译运行后输出Circle(center0.000000,0.000000, radius1.000000) Rectangle(0.000000,0.000000, 1.000000x1.000000) Line(0.000000,0.000000 - 1.000000,1.000000) Total perimeter: 9.595918整个过程有两个操作文本导出、周长计算但Circle、Rectangle、LineSegment三个类的代码完全没有因为新增操作而改动过。这就是开闭原则在实践中的体现。4.2 参数选择与代码设计背后的逻辑为什么accept的参数是Visitor而不是std::function因为std::function适合自由函数风格但访问者往往需要携带状态比如total、out而且需要一组互相有逻辑关系的重载。Visitor作为类天然把这些重载绑定在一起也让编译器能帮忙检查哪些节点还没处理。为什么traverse不用虚函数遍历因为std::vectorstd::unique_ptrShape的遍历本身就是线性地调用accept这个循环完全是多态无关的。真正的多态分发发生在accept内部这正是访问者模式把遍历结构和节点操作分离的体现。新增一个操作的步骤是这样的新建一个类继承Visitor实现所有visitXxx方法在main里创建对象并调用traverse。节点类一行不改原有代码零侵入。这套流程我后来一直在工程里用新增一个操作从写代码到跑通基本控制在半小时内。4.3 实操现场记录一次真实的扩展演示为了让你直观感受扩展容易我在上面的代码基础上模拟一次需求变更。产品经理说现在需要把图形信息导出为 XML。 我只需要新写一个类class XmlExporter : public Visitor { public: std::string out; void visitCircle(Circle c) override { out circle cx\ std::to_string(c.cx) \ cy\ std::to_string(c.cy) \ r\ std::to_string(c.radius) \/\n; } void visitRectangle(Rectangle r) override { out rect x\ std::to_string(r.x) \ y\ std::to_string(r.y) \ width\ std::to_string(r.width) \ height\ std::to_string(r.height) \/\n; } void visitLineSegment(LineSegment l) override { out line x1\ std::to_string(l.x1) \ y1\ std::to_string(l.y1) \ x2\ std::to_string(l.x2) \ y2\ std::to_string(l.y2) \/\n; } };改main两行XmlExporter xmlExporter; traverse(shapes, xmlExporter); std::cout xmlExporter.out;编译通过输出正确。这个过程中Shape体系零零改动。如果项目里Shape子类有成百上千种这种优势会成倍放大——因为你不再需要去碰那些又大又老的类文件只需要在一个新文件里专注写新逻辑。5. 访问者模式的 C 变体与替代方案5.1 std::variant std::visit现代 C 的轻量替代如果对象结构是封闭的也就是你知道所有类型且不想引入继承层级那么 C17 的std::variantstd::visit是现代 C 里比访问者模式更优雅的方案。思路其实异曲同工variant是类型安全的联合体std::visit是编译期生成的访问分发表。看代码#include variant #include vector #include iostream struct Circle { double radius 1.0; }; struct Rectangle { double width 1.0; double height 1.0; }; struct LineSegment { double x10, y10, x21, y21; }; using Shape std::variantCircle, Rectangle, LineSegment; int main() { std::vectorShape shapes; shapes.push_back(Circle{2.0}); shapes.push_back(Rectangle{3.0, 4.0}); shapes.push_back(LineSegment{0, 0, 3, 4}); auto visitor [](const auto s) { using T std::decay_tdecltype(s); if constexpr (std::is_same_vT, Circle) { std::cout Circle radius s.radius \n; } else if constexpr (std::is_same_vT, Rectangle) { std::cout Rect s.width x s.height \n; } else if constexpr (std::is_same_vT, LineSegment) { std::cout Line\n; } }; for (const auto s : shapes) { std::visit(visitor, s); } }这里std::visit在编译期就为你生成了一张分派表不需要手写accept。优点非常明显代码更短、性能更好很多场景下编译器直接生成跳转表、不需要继承、不会出现漏实现的运行时错误——因为编译器会检查 lambda 是否覆盖了所有分支。缺点同样明确类型列表封闭。你没法像虚函数那样随时通过新增子类扩展类型空间一旦要加Triangle所有用Shape的地方都要改。所以它适合节点类型固定、操作多变的场景比如表达式解析、协议解析。5.2 CRTP 静态多态版本性能敏感场景的选择有些底层场景游戏引擎、高频交易系统对虚函数调用开销很敏感。访问者模式天然依赖虚函数每次访问至少两次间接跳转一次accept一次visitXxx。这时候可以用 CRTP 把多态分派提前到编译期。template typename Derived class ShapeBase { public: template typename Visitor void accept(Visitor v) { static_castDerived*(this)-acceptImpl(v); } }; class Circle : public ShapeBaseCircle { public: double radius 1.0; template typename Visitor void acceptImpl(Visitor v) { v.visitCircle(*this); } };这样accept不再是虚函数编译期就完成了分派。代价是你失去了统一的Shape*基类指针不能再简单地std::vectorstd::unique_ptrShape了需要借助std::variant或类型擦除来管理异质容器。正常情况下我不推荐一上来就用 CRTP除非分析过热点确实在访问分派上。5.3 如何取舍一张决策对照表维度经典访问者模式std::variant std::visitCRTP 静态多态节点扩展性差新增节点要改所有 Visitor差必须一次性列出全部类型差编译期绑定操作扩展性好新增 Visitor 即可好新增 std::visit 调用即可好运行时开销两次虚调用/访问接近于零零编译期分派代码直观度一般accept/visit 互相调用较好lambda 内集中较低模板代码难调试适合场景大型继承体系、AST、需要类型擦除封闭类型集、性能敏感极致性能、类型集封闭我个人的经验是能用std::variant就先别上访问者。只有当节点有复杂继承关系、或者必须用unique_ptrBase管理异质对象、或者需要支持运行时新增节点类型的插件体系时经典访问者才真正发挥优势。6. 常见问题与排查技巧实录6.1 新增节点类型后编译全挂这是设计使然很多人在给访问者体系新增一个节点类型时发现每个 Visitor 都要加一个新方法代码量爆炸。这不是 bug这是访问者模式的核心权衡——新增节点成本高新增操作成本低。但如果项目里节点类型确实可能频繁增长我建议在架构早期就改用std::variant或者把访问者设计成默认走visitUnknown的形式class Visitor { public: virtual void visitCircle(Circle c) { visitUnknown(c); } virtual void visitRectangle(Rectangle r) { visitUnknown(r); } virtual void visitUnknown(Shape s) { throw std::runtime_error(Unsupported shape type); } };这样新增节点类型时现有 Visitor 不需要全部改动只有真正需要处理新类型的 Visitor 才去重写对应方法。代价是visitUnknown的兜底行为容易掩盖逻辑错误所以我只在节点类型可能增加但频率较低的保守场景中使用它。6.2 accept 没加 override一道难以察觉的隐患Shape基类的accept如果没有正确加override子类的accept会静默地变成一个全新的虚函数而不是覆盖基类版本。这种 Bug 在大型继承树里极难发现因为代码依然能编译、能运行但多态分派链路会断掉。排查方法是每次写完accept都加override关键字——这不仅是 C11 的规范更是编译器帮自己检查错误的工具。如果基类没有对应的虚函数编译器会直接报错。还有一个隐蔽的坑accept的参数是Visitor如果某个子类手滑写成了Visitor v按值传递编译器不会报错但会发生对象切割访问者里所有状态全部丢失。我在代码评审里至少抓到过三次这种问题。6.3 遍历期间修改容器引发的未定义行为访问者经常被用来遍历容器并就地修改节点比如把所有圆形半径放大一倍。如果访问者内部直接往容器里push_back新元素会导致迭代器失效轻则漏访问重则直接崩溃。我的习惯是访问者只负责读取或修改节点自身不负责修改容器结构。容器结构的增删统一放到遍历外层处理。举个例子// 反例遍历时删除当前元素 for (auto it shapes.begin(); it ! shapes.end(); it) { (*it)-accept(removeVisitor); // 如果这里 erase这个循环就炸了 } // 正例先收集再统一删除 RemoveVisitor removeVisitor; for (auto s : shapes) s-accept(removeVisitor); for (auto* doomed : removeVisitor.toRemove) { // 外层再执行实际删除 }6.4 访问者内部状态与多线程如果同一个Visitor实例被多个线程同时使用它的内部状态比如total、out一定会出现数据竞争。解决思路有两种每个线程创建自己的 Visitor 实例最后合并结果访问者内部用thread_local存储或者状态通过参数传递而不是成员变量。我自己更倾向于第一种简单直观副作用少。7. 关于访问者模式我最想让你记住的几件事技术细节讲完最后聊点实在的。第一访问者模式不是银弹。它的核心价值在于稳定结构 多变行为一旦这个前提不存在它会变成维护噩梦。所以用之前先问自己两个问题这个对象结构真的稳定吗这些操作真的会频繁增加吗如果答案都是是再动手实现。第二在 C 里用访问者模式比在 Java 里用要多操心一层引用还是值、拷贝还是移动、虚函数还是模板、生命周期归谁管。这些细节处理不好模式不但帮不上忙还会引入新的 Bug。我的经验是先把最朴素的版本写对再考虑 CRTP 或std::variant之类的优化方案。第三如果你是团队里第一个引入访问者模式的人一定要给其他成员留一份简短的使用说明。因为这套代码的调用链确实绕外部调acceptaccept调visitXxxvisitXxx访问节点成员。新同事如果没看过模式介绍很容易在accept和visit的互相调用里绕晕。我在团队 Wiki 里留了个快速指南到现在还有人在看。最后再分享一个实用的细节我用访问者模式的时候会在每个Visitor子类里放一句注释标明这个 Visitor 代表什么操作、由谁触发、输出写到哪。等过了三个月再回来改代码这句注释能帮你省下大量重新理解上下文的时间。如果你现在正准备在项目里用访问者模式我建议先写一个小规模的原型把你真实的节点类型塞进去跑一遍感受一下新增操作不动原类这个特性带来的变化。试过之后你就会明白这个模式被收录进 GoF 经典模式列表的原因了。