go语言中直接套用经典访问者模式别扭，因其缺乏方法重载和运行时双分派支持，硬搬会导致大量类型判断或反射，违背解耦初衷；应采用接口+类型断言的手动双分派方式，并按场景拆分小接口、避免大而全的visitor。
为什么 Go 语言里直接套用经典访问者模式会别扭
因为 Go 没有方法重载，也不支持运行时类型双分派（double dispatch），而经典访问者模式依赖这两点来让 VisitElementA() 和 VisitElementB() 自动分发到对应实现。硬搬 Java/C++ 的写法会导致大量 if elem.Type == "A" 或反射判断，失去模式本意——把操作逻辑从数据结构中解耦出来。
用 interface{} + 类型断言模拟访问者行为
这是最常用、也最符合 Go 习惯的做法：定义统一的 Accept() 方法，由具体元素决定调用哪个访问者方法；访问者接口按需暴露不同参数类型的 VisitXXX() 方法，内部用类型断言区分。
-
Element接口只声明Accept(v Visitor)，不暴露内部结构 -
Visitor接口方法签名必须显式接收具体类型（如VisitFile(*File)、VisitDir(*Dir)），不能只写Visit(interface{}) - 每个具体元素的
Accept()实现里，直接调用v.VisitFile(f)或v.VisitDir(d)—— 这是手动完成“双分派”
func (f *File) Accept(v Visitor) { v.VisitFile(f) }
func (d *Dir) Accept(v Visitor) { v.VisitDir(d) }
避免在 Visitor 接口里塞太多方法
一旦元素类型变多（比如新增 Symlink、Device），就要同步改 Visitor 接口和所有实现，违反开闭原则。更务实的做法是：
- 按业务场景拆分访问者：比如
SizeCalculator只关心大小，PathPrinter只关心路径遍历，各自定义最小接口 - 用组合代替继承：一个结构体嵌入多个小 Visitor 接口，而不是实现一个巨无霸
FullVisitor - 如果真需要泛化处理，宁可接受一次类型断言（
if f, ok := elem.(*File); ok { ... }），也比强推抽象接口更清晰
什么时候该放弃访问者模式
Go 里多数时候，直接写个函数更简单：
立即学习“go语言免费学习笔记（深入）”；
- 元素结构稳定、操作逻辑简单 → 用
func Walk(e Element, fn func(Element)) - 需要收集多种结果（如统计+打印+校验）→ 用回调函数或 channel 返回中间结果
- 涉及复杂状态流转（如解析 AST 后做语义检查）→ 考虑用访问者，但优先封装成私有结构，避免暴露大接口
真正卡住的不是语法，而是想当然地认为“设计模式必须原样移植”。Go 的接口是隐式的、组合是第一等公民、类型系统偏保守——这些特性天然排斥那种靠继承树和重载堆出来的访问者结构。
