go实现访问者模式需避免三坑：runtime panic（visitor接口必须显式覆盖所有节点类型）、漏类型（accept与visit必须严格同步）、维护爆炸（用funcvisitor替代struct实现）。
Go 里写访问者模式不难，但硬套 Java 那套会踩 runtime panic、漏类型、维护爆炸三个坑。核心不是“怎么实现”，而是“怎么避免让 Accept 和 Visit 方法不同步”。
Visitor 接口必须显式覆盖所有节点类型
Go 没有泛型约束和重载，Visitor 接口里每个 VisitXxx 方法都得手动对应到具体结构体。漏一个，运行时遇到该类型就 panic —— 编译器完全不报错。
-
Visitor接口声明了VisitFile、VisitDir、VisitSymlink，那所有节点类型就必须有对应的Accept实现 -
*File的Accept必须调用v.VisitFile(f)，不能写成v.VisitDir(f)（类型错配） - 新增
*Archive类型？得同步补：func (a *Archive) Accept(v Visitor)+Visitor接口加VisitArchive+ 所有已存在的FuncVisitor实现也得加字段
用 FuncVisitor 替代 struct 实现避免爆炸式增长
为每种操作（打印、校验、序列化）都写一个 PrintVisitor、ValidateVisitor 结构体，很快就会失控。改用函数值封装行为更轻量，也更容易组合。
- 定义
FuncVisitor结构体，字段全是func(*T)，每个方法只是转发调用 - 使用时直接传匿名函数：
walk(root, FuncVisitor{VisitFile: func(f *File) { log.Printf("size: %d", f.Size) }}) - 多个行为想复用？把
FuncVisitor当参数传给工具函数，而不是嵌套 struct - 注意：如果需要状态（比如累计文件数），闭包变量够用；如果状态复杂或需并发安全，再退回到 struct + mutex
遍历逻辑必须由节点自己控制，不能甩给 Visitor
别让 Visitor 去递归子节点 —— 这会让遍历逻辑和业务逻辑耦合，且无法处理循环引用、剪枝等边界情况。
-
*Dir的Accept方法里负责遍历d.Children并对每个子节点调用c.Accept(v) - Visitor 只管“当前节点做什么”，不管“接下来去哪”
- 如果子节点可能为空（
nil）、或存在环（软链接指向父目录），这些检查必须在Accept内部做，Visitor 不该感知 - 想提前终止遍历？在
Accept里加返回值（如bool表示是否继续），比在 Visitor 里设标志位更清晰
AST 场景下别写 Accept，用 ast.Inspect + 类型断言
标准库 ast.Node 是空接口，没法加 Accept 方法。强行给每个 ast.*Expr 补实现既不可行也不必要 —— 直接用 ast.Inspect 更符合 Go 惯用法。
ast.Inspect(f, func(n ast.Node) bool { if call, ok := n.(*ast.CallExpr); ok { /* 处理 */ } return true })- 返回
false可剪枝，避免进入子树；返回true继续遍历 - 别在
if块里直接用n.(*ast.Ident)—— 先判断n != nil，再断言，否则遇到nil字段（如FuncDecl.Recv）直接 panic - 需要多规则并行扫描？换
golang.org/x/tools/go/ast/inspector，它支持批量匹配类型、跳过注释、复用实例
最易被忽略的一点：Visitor 接口的方法签名一旦定下，就等于锁死了节点类型的公开结构 —— 因为每个 VisitXxx 都强依赖具体指针类型。所以与其花时间设计“完美 Visitor”，不如先确保 Accept 在所有节点上都正确分发，再用 FuncVisitor 快速验证行为逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
