在Go里写访问者模式，其实不算难，但要是硬搬Ja va那套模板，很容易踩到几个坑。核心不在于“怎么实现”，而在于“怎么避免让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快速验证行为逻辑。
