c++访问者模式必须靠虚函数+手动类型识别，因其缺乏原生双分派支持；单靠virtual仅实现第一次分派（调用方动态类型），第二次分派（被访元素具体类型）需visitor在visit()重载中手动dispatch。
为什么 C++ 里访问者模式必须靠虚函数 + 手动类型识别？
因为 C++ 没有原生双分派支持。单靠 virtual 只能实现「第一次分派」（调用方对象的动态类型），第二次（被访问元素的具体类型）得靠 visitor 自己在 visit() 重载里手动 dispatch——本质是把运行时类型判断从编译器挪到程序员手上。
常见错误现象：visit(Base&) 被所有子类匹配，子类特化版本根本没进；或者 visitor 接口漏加某个子类的 visit() 声明，导致编译失败但报错位置离实际问题很远。
- 必须让每个可被访问的类（
Element子类）都实现accept(Visitor&)，且内部必须写死v.visit(*this)——不能写v.visit(static_cast<derived>(*this))</derived>，否则失去多态性 -
Visitor接口里的每个visit()函数参数类型必须精确对应一个Element子类，不能全用基类引用，否则退化成单分派 - 如果新增一个
Element子类，必须同步修改所有Visitor实现类，漏改就会编译报错：no matching function for call to 'VisitorImpl::visit(Derived&)'
visitor 接口设计：纯虚 vs 模板，哪个更实用？
用纯虚函数接口是主流选择，模板方案（比如 CRTP）看似省去虚函数开销，但会让 visitor 变成泛型类，无法统一传参、无法存入容器、无法运行时切换策略——直接废掉访问者模式最核心的「解耦操作与结构」价值。
典型使用场景：AST 遍历、序列化、语法树语义检查。这些地方需要统一管理一组 visitor 实例，或按配置加载不同 visitor。
立即学习“C++免费学习笔记（深入）”；
- 接口定义要窄：只暴露必要的
visit()，避免把visit(Expression&)和visit(Statement&)合并在一个重载里 - 参数一律用非 const 引用（
visit(Expression&)），方便 visitor 修改节点（如 AST 重写）；若只读，再加 const 版本，但别混用 - 不要在
visit()里抛异常来中断遍历——这会让控制流不可预测；改用返回值（如bool）或状态标记
accept() 实现最容易踩的坑：static_cast 和 this 的陷阱
最常写的错法：void Derived::accept(Visitor& v) { v.visit(*this); } 看似没问题，但如果 Visitor 接口里只有 visit(Base&)，那它就真调到了基类版本——C++ 重载解析在编译期决定，不看 *this 实际类型。
正确做法只有一个：v.visit(static_cast<derived>(*this))</derived>，强制告诉编译器“我确定这是 Derived”，才能触发正确的重载。
- 不能用
dynamic_cast替代static_cast：性能差，且 visitor 不该承担类型安全校验责任 - 如果
Derived是模板类（如TemplateNode<t></t>），accept()必须是模板成员函数，否则无法生成对应visit()调用 - 基类
Base::accept()不要提供默认实现，否则子类忘记重写时会静默调用基类版本，引发逻辑错误
std::variant + std::visit 能替代传统访问者模式吗？
可以简化简单场景，但不能替代。它解决的是「单个值的类型分支」，而经典访问者模式解决的是「异构容器中多种节点的统一遍历+操作」。
比如你有一组 std::vector<:variant stmt decl>></:variant>，用 std::visit 确实能避免手写 accept()，但一旦需要递归下降（如遍历 AST 子节点）、需要共享状态（如符号表）、需要跨节点传递上下文，std::variant 就力不从心了。
-
std::visit的 visitor 是函数对象，无法保存中间状态；传统 visitor 是类，天然支持成员变量 - 没有
accept()方法，你就没法把遍历逻辑封装进节点内部，违背了“数据和操作分离”的原始意图 - 如果节点类型超过 10 个，
std::variant<...></...>编译时间和二进制体积会明显上涨，而虚函数方案无此压力
真正容易被忽略的点：访问者模式不是为了炫技，而是当「操作种类多、数据结构稳定」时，比在每个节点里塞一堆 if (type == X) doX() 更易维护。一旦数据结构开始频繁增删类型，这个模式反而会成为负担。
