Go中Visitor模式需严格对齐元素类型：Visitor接口须为每种Element子类型定义独立Visit方法，Accept由各具体类型实现并直接调用对应Visit，避免反射或基类统一分发；多数场景推荐filepath.Walk+type switch等轻量方案。
Visitor 接口定义要和具体元素类型严格对齐
Go 没有泛型约束下的多态重载，Visit 方法不能靠参数类型自动分发——你得手动为每种 Element 子类型定义对应方法。常见错误是只写一个 Visit(e interface{})，结果运行时 panic 或逻辑跳过。
正确做法是让 Visitor 接口包含明确的、一一对应的访问方法：
type Visitor interface {
VisitFile(*File)
VisitDirectory(*Directory)
}
- 每个
Element实现自己的Accept(v Visitor)，内部调用v.VisitXxx(this) - 如果新增
SymbolicLink类型，必须同步在Visitor接口中加VisitSymbolicLink(*SymbolicLink)，否则编译不通过，这是好事 - 别试图用反射或
interface{}绕过——失去类型安全，调试成本远高于多写两行方法
Accept 方法必须由具体 Element 实现，不能放在基类
Go 没有继承意义上的“基类”，所谓“元素基类”通常只是普通 struct 或接口。如果把 Accept 放在通用接口里并默认实现，会导致所有子类型共享同一份分发逻辑，无法差异化处理。
典型错误：定义 type Element interface { Accept(Visitor) } 后，在某个 helper 函数里统一 dispatch，结果所有类型都走同一个分支。
立即学习“go语言免费学习笔记（深入）”；
- 每个具体类型（如
*File、*Directory）各自实现Accept -
Accept体内直接调用v.VisitFile(this)或v.VisitDirectory(this)，不经过中间映射或 switch - 这样能保证类型精确匹配，也方便 IDE 跳转和静态分析
双分派失效时别硬套 Visitor
Visitor 模式本质依赖“双分派”：第一次靠 e.Accept(v) 分发到具体 Element，第二次靠 v.VisitXxx() 分发到具体 Visitor 实现。但 Go 中若 Visitor 实现分散在不同包、或需动态注册，就容易断链。
常见踩坑场景：
- 把
Visitor定义在visitor/包，而File在fs/包，Accept方法要 importvisitor，形成循环依赖 - 想支持插件式 Visitor（比如从 JSON 加载行为），但
VisitXxx是接口方法，无法动态绑定 - 实际只需遍历+简单处理（如统计大小），用
WalkFunc+ 闭包更轻量，强行 Visitor 反而增加抽象层级
替代方案比硬写 Visitor 更常用
真正在 Go 项目里，90% 的“想用 Visitor”的需求，最后落地是更朴素的方式：
- 用
filepath.Walk或fs.WalkDir配合switch e.Type()处理不同类型节点 - 把算法逻辑封装成函数，接收
fs.DirEntry或自定义Node接口，内部用 type switch 判断 - 需要组合多个操作？用函数选项模式：
Process(...Option)，每个Option是个闭包，按需叠加
Visitor 在 Go 里不是“推荐模式”，而是“当结构稳定、访问逻辑爆炸增长、且跨包协作强约束时才值得引入”的权衡选择。多数时候，少一层抽象，代码反而更可靠。
