Go中不推荐直接使用访问者模式，因其缺乏方法重载和运行时类型分发，强行模拟需type switch或反射，导致类型不安全、维护困难、易panic；业务系统应优先选用函数式处理、接口组合或代码生成等更轻量安全的替代方案。

访问者模式在 Go 语言中**天然受限，不推荐直接照搬用于业务系统**。根本原因在于 Go 没有方法重载、没有运行时类型分发（如 Java 的 visit(ConcreteElement) 多态调用），强行模拟会导致大量 type switch 或反射，既难维护又易出错。

为什么 Go 里写标准访

问者模式会出问题

典型错误是试图用接口+空接口+type switch 模拟双分派：

// ❌ 常见反模式：把所有 Element 类型塞进一个 visitor 接口
type Visitor interface {
    Visit(e interface{}) // 参数是 interface{}，完全失去类型安全
}
func (v *MyVisitor) Visit(e interface{}) {
    switch e.(type) {
    case *User: v.visitUser(e.(*User))
    case *Order: v.visitOrder(e.(*Order))
    // ……每加一个元素类型就要改这里
    }
}

这种写法的问题很实际：

• Visit 方法无法静态检查传入类型，IDE 和 go vet 都帮不上忙
• 新增 Product 类型？必须同步修改所有 Visitor 实现里的 switch 分支
• 编译期无法发现漏掉的 case，运行时 panic 风险高
• 无法利用 Go 的结构体嵌入和组合特性，反而让代码更“面向对象化”

业务系统更可行的替代方案

Go 业务系统真正需要的是「对一组异构结构做统一处理」的能力，而不是设计模式教科书上的访问者。更轻量、更安全的做法包括：

• 用函数式风格：定义统一处理函数 func(e Element) error，配合切片遍历 —— 简单、可测试、无反射
• 用接口+方法组合：让每个业务结构实现 Accept(v Visitor)，但 Visitor 接口只声明具体方法（如 VisitUser(*User)），由具体结构自己调用对应方法 —— 类型安全，新增类型只需实现 Accept，不破坏已有 visitor
• 用代码生成（go:generate + stringer 或自定义模板）：根据结构体字段或标签自动生成 Accept 方法，避免手写重复逻辑

什么场景下可以考虑“类访问者”逻辑

仅当满足以下全部条件时，才值得引入接近访问者语义的设计：

• 存在稳定、极少变更的元素类型集合（比如 AST 节点：*ast.CallExpr、*ast.BinaryExpr）
• 需要频繁添加新操作（如格式化、校验、转译），且这些操作逻辑高度依赖元素内部结构
• 团队能接受为每种元素类型写一个 VisitXXX 方法，并用工具保证接口实现完整性

即便如此，也建议用 interface{ Accept(Visitor) } + 具体方法签名，而非泛化 Visit(interface{})。

真正容易被忽略的是：业务系统里 80% 的“需要访问者”的需求，其实只是想解耦数据结构和业务逻辑。用简单函数、策略接口或者命令模式就能解决，没必要套一层访问者壳子 —— 尤其当团队里没人能说清 double dispatch 在 Go 里怎么落地的时候。