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语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
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 分支，导致静默失效。
