Golang访问者模式：算法与结构分离详解

在Go中实现访问者模式并非简单的语法糖，而是一种需要开发者严格遵循规则的结构隔离方案：必须为每种元素类型显式定义匹配的Visit方法和指针接收者的Accept方法，依靠两次手动函数调用（e.Accept(v) → v.VisitXxx(e)）完成类型安全的双分派，彻底拒绝interface{}或反射带来的运行时不确定性；它用编译期强制的冗余声明（如新增类型需同步扩展接口和所有实现）换取算法与数据结构的彻底解耦，同时要求visitor保持无状态、遍历逻辑由元素自身驱动，从而在保证类型安全、性能和并发安全的前提下，真正实现“结构稳定、行为可插拔”的设计目标。

Visitor 接口定义要匹配具体 Element 类型的 Accept 方法

Go 没有泛型接口多态（直到 Go 1.18+ 的约束仍不支持运行时类型擦除），所以 Visitor 不能只写一个 Visit 方法试图接收所有 Element。否则编译报错：cannot use v (variable of type *MyVisitor) as Visitor value in argument to e.Accept: *MyVisitor does not implement Visitor (wrong type for Visit method)。

必须为每种 Element 子类型显式声明对应方法：

type Visitor interface {
    VisitFile(*File)
    VisitDirectory(*Directory)
}

对应地，每个 Element 实现自己的 Accept，只调用 visitor 上那个**唯一匹配的方法**：

func (f *File) Accept(v Visitor) {
    v.VisitFile(f) // 不是 v.Visit(f)
}

• 别在 Visitor 里塞 Visit(interface{}) —— 失去类型安全，后续还得类型断言，违背 Visitor 初衷
• 如果新增 SymbolicLink 类型，必须同步扩写 VisitSymbolicLink 和所有已存在 visitor 实现，这是编译期强制的“扩展成本”
• 接受这种冗余，恰恰是换取算法与结构分离的代价

Accept 方法必须接收 *this 而非 this

Go 中方法接收者若用值类型（func (f File) Accept(v Visitor)），会导致 f 是副本，内部修改不反映到原结构；更关键的是，当 File 包含指针字段（比如 content *bytes.Buffer）时，值接收者会浅拷贝指针，看似能改，但语义混乱且易引发并发误用。

标准做法是统一用指针接收者：

func (f *File) Accept(v Visitor) {
    v.VisitFile(f)
}

• 所有 Element 类型的 Accept 方法签名必须一致：指针接收者 + Visitor 参数
• 如果某类忘记加 *，编译器不会报错，但运行时可能 panic 或逻辑错位（尤其涉及嵌套结构遍历时）
• 别为了“看起来简洁”用值接收者 —— Visitor 模式本质是双向耦合：结构告诉 visitor “我是谁”，visitor 告诉结构 “我要怎么处理你”，这个过程必须可变、可追踪

双分派靠两次函数调用完成，不是靠 interface{} 或反射

Visitor 模式的双分派在 Go 里是手动编码出来的：第一次分派是 e.Accept(v)（由具体 Element 类型决定调哪个 Accept），第二次是 v.VisitXxx(e)（由 Visitor 具体实现决定行为）。它不依赖 interface{} 或 reflect，否则就退化成策略模式或弱类型遍历了。

典型错误是试图“通用化”：

// ❌ 错误：用 interface{} 消融类型
func (v *CountingVisitor) Visit(e interface{}) {
    switch e.(type) {
    case *File: ...
    case *Directory: ...
    }
}

• 这样写丢失编译检查，新增类型时不会报错，只有运行时才发现漏 case
• 性能上，switch e.(type) 是运行时类型判断，比直接函数调用慢 2–3 倍（基准测试可验证）
• 真正需要动态类型的场景（如插件化 visitor），应另建注册表 + 显式映射，而不是在 Visit 内部做类型分支

嵌套结构遍历中，Visitor 不该持有状态指针

常见误区：把计数器、路径栈等状态放在 Visitor 结构体字段里，然后在 VisitDirectory 中递归调用子节点 Accept。这会导致 visitor 在多 goroutine 并发访问同一树时数据竞争。

正确做法是让遍历逻辑（即 Accept 链）驱动 visitor，状态通过参数传递或闭包捕获：

func (d *Directory) Accept(v Visitor) {
    v.VisitDirectory(d)
    for _, child := range d.Children {
        child.Accept(v) // 让 child 自己决定怎么传 v
    }
}

• 如果 visitor 真需维护上下文（如当前深度），应在每次 Accept 调用时作为额外参数传入，或用函数式风格构造新 visitor 实例
• 别在 visitor 方法里启动 goroutine 并共享字段 —— Go 的并发模型要求状态归属清晰
• 最稳妥的方式是把 visitor 设计为无状态接口，所有上下文由调用方管理（比如用 Walk 函数封装整个遍历流程）

事情说清了就结束。Visitor 在 Go 里不是语法糖，它是靠接口方法名硬编码、靠编译器强制校验、靠开发者手动维护一致性换来的结构隔离 —— 少一个 *，少一个方法声明，少一次显式调用，整个模式就塌一半。

本篇关于《Golang访问者模式：算法与结构分离详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！