Golang访问者模式(Visitor)_在不修改结构的前提下增加操作

visitor接口必须为每种element类型显式定义visit方法（如visitfile、visitDirectory），且每个element的accept方法需调用对应visit，确保编译期类型安全与遍历正确性。

Visitor 接口定义必须匹配所有 Element 类型

go 没有泛型约束下的多态重载，所以 Visit 方法签名得提前覆盖所有可能被访问的 Element 实现类型。不是写一个 Visit(e Interface{}) 就完事——那样会失去类型安全，也违背 Visitor 的本意。

常见错误是只定义 Visit(*File)，结果遇到 *Directory 就 panic 或静默跳过。

• 每个 Visitor 实现必须显式声明所有 VisitXXX() 方法，比如 VisitFile(*File)、VisitDirectory(*Directory)
• 对应地，每个 Element 的 Accept(v Visitor) 方法里，必须调用 v.VisitXXX(this)，不能漏掉分支
• 如果新增一种 *Link 结构，就要同步在所有已存在的 Visitor 实现里补上 VisitLink(*Link) ——这是“不修改结构但增加操作”的代价：Visitor 实现要扩展，而非 Element

Accept 方法必须由 Element 自己调用 Visit，不能反向

有人会把逻辑反过来：让 Visitor 主动判断 e.(type) 再分发，这本质上退化成了 if-else 类型检查，既难维护又绕开 Go 的接口机制。

正确路径是让每种 Element 自己知道“我该触发哪个 Visit 方法”，把分发权交给数据结构本身。

立即学习“go语言免费学习笔记（深入）”；

• File.Accept(v Visitor) 体内写死 v.VisitFile(f)，而不是 v.Visit(f) 然后靠反射或类型断言
• 这样能保证编译期检查：如果某个 Visitor 忘了实现 VisitFile，代码直接报错，不会等到运行时才发现
• 递归遍历时（比如 Directory.Accept 遍历子节点并调用 child.Accept(v)），也是靠每个子节点自己决定调哪个 Visit，不是 Visitor 统一分发

Go 里没有虚函数，所以 Accept 必须显式实现

不像 C++/Java，Go 的接口方法不自动继承。哪怕 File 和 Directory 都实现了 Element 接口，它们的 Accept 方法也得各自写一遍，没法共用父类逻辑。

容易踩的坑是试图用嵌入（embedding）+ 匿名字段模拟基类，结果发现嵌入的 Accept 方法无法根据实际类型调用正确的 Visit。

• 每个 Element 类型都要独立实现 Accept(v Visitor)，哪怕内容看起来重复
• 别为了省几行代码把 Accept 提到某个工具函数里，传 interface{} 进去再断言——那等于放弃类型安全
• 如果多个 Element 共享相似结构（比如都有 Name String），可以提取字段，但 Accept 仍需各自实现

性能敏感场景慎用，避免过度抽象

Visitor 在 Go 里本质是一层额外的间接调用 + 接口动态分发。对高频小对象（比如每秒百万次的 AST 节点遍历），它比直接写 if-else 或 switch 多一次方法查找和栈帧开销。

不是模式不好，而是 Go 的轻量哲学和 Visitor 的经典用途存在张力：Visitor 适合“操作种类多、结构稳定”的场景；而 Go 更常见的是“结构常变、操作不多”。

• 如果只有两种操作（比如 print() 和 Size()），直接给每个 Element 加两个方法更清晰
• 如果真要用 Visitor，避免在 Visit 方法里做耗时操作（如 IO、加锁），否则会拖慢整个遍历链
• 注意循环引用：Visitor 不该持有对 Element 树的强引用，否则 GC 压力大，尤其树很深时

Visitor 模式在 Go 里真正起作用的地方，是当你有一组稳定的结构体，但业务侧不断冒出新需求要“对它们统一做某件事”——比如导出为 json/YAML、生成文档、校验权限、计算哈希。这时候，每次加功能不用碰老结构，只要写个新 Visitor。但前提是，你愿意为每个新结构类型，在每个已有 Visitor 里补方法——这个“契约”得所有人心里有数，不然很快就会漏掉一个 Visit 分支，导致静默失效。