go中visitor模式需手动实现双分派：因无运行时多态，visitor接口须为每种元素定义独立visit方法，否则编译期无法检查、易panic；accept宜用指针接收器；可用funcvisitor简化实现，但需防循环引用与维护成本。
Go 语言里想靠访问者模式做双分派扩展，本质是手动模拟——没有虚函数表，也没有方法重载，Accept 和 Visit 必须成对显式实现，漏一个就 panic。
为什么 Go 的 Visitor 接口必须为每种元素定义独立方法
因为 Go 没有运行时多态分发机制。如果只定义一个 Visit(e interface{})，访问者内部就得靠 type switch 或类型断言判断具体类型，既容易漏分支，又失去编译期检查。
- 新增一种元素（比如
*ConfigNode），就必须在所有已存在的Visitor实现中补上VisitConfigNode方法，否则调用node.Accept(v)时会 panic：method not implemented - IDE 无法自动提示缺失方法，全靠人工核对；接口膨胀快，
Visitor可能迅速变成十几个VisitXXX方法的集合 - 好处是类型安全：编译器能确保
v.VisitFile(f)的参数类型匹配，不会传错指针/值、也不会传错结构体变体
Accept 方法该用值接收器还是指针接收器
取决于你是否需要在 Accept 内部修改元素状态，或是否希望支持值类型和指针类型混用。
- 用指针接收器（
func (e *File) Accept(v Visitor)）更常见：避免复制大结构体，且与大多数 Go 接口约定一致（如io.Reader） - 用值接收器（
func (e File) Accept(v Visitor)）时，VisitFile参数也得是值类型，否则接口不满足；但这样无法在访问逻辑中修改原始File实例 - 混合使用会破坏一致性：若
File用值接收器而Folder用指针接收器，调用方需注意传参方式，易出错
如何避免写一堆 ConcreteVisitor struct
多数场景下，访问逻辑是轻量、一次性的，没必要为每个操作建 struct。用函数值封装更符合 Go 风格。
- 定义
FuncVisitor类型，字段是各Visit*对应的函数签名 - 实现
VisitFile等方法时，直接调用对应字段函数，不做额外状态管理 - 调用时传匿名函数：
walk(root, FuncVisitor{VisitFile: func(f *File) { log.Printf("size: %d", f.Size) }}) - 缺点是闭包捕获外部变量可能造成内存泄漏或竞态；需谨慎处理状态共享
递归遍历中容易忽略的循环引用问题
当对象结构含环（比如 AST 中节点双向引用、图结构、带 parent 指针的树），Accept 递归调用会无限深入，最终栈溢出或 panic。
- 不能依赖访问者自己维护 visited 集合——那会让
Visitor承担结构遍历职责，违背“操作与结构分离”初衷 - 应在
Element层控制：比如Folder.Accept内部显式跳过已访问过的子节点，或由上层ObjectStructure统一管理遍历上下文 - 更稳妥的做法是把遍历逻辑抽到单独函数（如
Walk），让Visitor只负责单点操作，不参与控制流
真正难的不是写出第一个 VisitFile，而是后续每次加新元素时，要同步更新所有 Accept 实现和所有 Visitor 接口及其实现——这个维护成本，比用 type switch 集中分发高得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
