Go语言中标准访问者模式别扭，因其缺乏方法重载与静态多态，导致接口膨胀、维护困难；推荐用type switch+函数值替代，兼顾扩展性与简洁性。
为什么 Go 语言里“标准”访问者模式写起来别扭
Go 没有方法重载、没有子类型多态（编译期静态分发）、接口实现是隐式的——这些直接导致照搬 Java/C++ 的访问者模式会失控：你得手动维护 Accept 方法的调用链，每个新元素类型都要改访问者接口，每加一个访问者就得补全所有 VisitXXX 方法。这不是设计模式，是维护噩梦。
用 interface{} + type switch 替代 Visitor 接口枚举
更符合 Go 习惯的做法是让访问逻辑集中、开放扩展：定义统一入口函数，用 type switch 分派具体行为，而不是靠一堆 Visit* 方法塞进接口。这样新增元素类型只需在 switch 中加 case，不破环已有代码。
示例：
func Walk(node interface{}, fn func(interface{}) error) error {
switch n := node.(type) {
case *BinaryNode:
if err := fn(n); err != nil {
return err
}
if n.Left != nil {
if err := Walk(n.Left, fn); err != nil {
return err
}
}
if n.Right != nil {
if err := Walk(n.Right, fn); err != nil {
return err
}
}
case *LeafNode:
return fn(n)
default:
return fmt.Errorf("unsupported node type: %T", n)
}
return nil
}
- 所有节点类型只要满足“能被
type switch匹配”，就自动接入遍历逻辑 -
fn是闭包，可携带上下文（如计数器、错误收集器），比固定接口更灵活 - 没有
Visitor接口要实现，也没有Accept方法要嵌入到每个结构体中
当真需要双分派时，用组合 + 显式 dispatch 函数
极少数场景（比如渲染器需根据节点类型和输出格式做组合判断），可以接受轻微重复：为每对组合写一个 dispatch 函数，而非强行抽象成接口。例如：
立即学习“go语言免费学习笔记（深入）”；
func RenderAsHTML(node Node, w io.Writer) error {
switch n := node.(type) {
case *Text:
return renderTextAsHTML(n, w)
case *Image:
return renderImageAsHTML(n, w)
}
}
func RenderAsMarkdown(node Node, w io.Writer) error {
switch n := node.(type) {
case *Text:
return renderTextAsMarkdown(n, w)
case *Image:
return renderImageAsMarkdown(n, w)
}
}
- 函数名明确表达意图，调用方一目了然
- 新增格式只需加一个函数，不影响旧逻辑；新增节点类型只需在各函数中补 case
- 避免把 dispatch 规则藏在接口方法名里（如
AcceptHTMLRenderer），那种写法在 Go 里既难查又难测
别给 struct 嵌入 Accept 方法——那是自找麻烦
常见反模式：在每个节点 struct 里写 func (n *X) Accept(v Visitor) { v.VisitX(n) }，再定义 Visitor 接口。问题在于：
- 每加一个节点类型，就要改
Visitor接口，所有实现都得同步更新 - Go 接口无法“部分实现”，哪怕只用其中两个方法，也得实现全部
- 测试时无法 mock 单个 visit 行为，只能整块替换 visitor 实例
- IDE 跳转找不到所有
Visit*调用点，因为它们是动态分发的
真正需要隔离访问逻辑时，用函数类型或带字段的 struct 封装行为更直接，比如：type Renderer struct { HTMLWriter io.Writer; MarkdownWriter io.Writer }，然后按需调用其内部方法。
访问者模式的核心诉求是“分离算法与数据结构”，但在 Go 里，用组合、函数值和清晰的控制流就能做到，不必强套四人帮那套契约。硬套只会让代码变脆、变难读、变难改。
