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 业务系统真正需要的是「对一组异构结构做统一处理」的能力，而不是设计模式教科书上的访问者。更轻量、更安全的做法包括：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“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 里怎么落地的时候。
