Go 的 ast.Node 接口不适合传统访问者模式，因其无 Accept 方法，需用 ast.Inspect/ast.Walk 配合类型断言实现轻量遍历；Inspect 支持剪枝，Walk 适合统计；状态管理应封装结构体；x/tools/inspector 提供类型批量匹配与作用域支持；边界情况如 nil List、_ 标识符、泛型节点易被忽略。
为什么 Go 的 ast.Node 接口不适合直接用传统访问者模式？
Go 标准库的 ast 包里，ast.Node 是个空接口，没有 Accept 方法——这意味着你没法像 Java 或 C++ 那样让每个节点自己调用 visitor.VisitXXX()。强行补 Accept 要改源码或大量类型断言，不现实。
实际做法是：用 ast.Inspect 或 ast.Walk 遍历，把“访问逻辑”收拢到一个函数里，靠类型判断分发。这不是教科书式的访问者，但它是 Go 里最轻、最稳、最符合惯用法的替代方案。
-
ast.Inspect返回bool控制是否继续遍历子树，适合需要剪枝的场景（比如只分析函数体，跳过注释） -
ast.Walk不返回值，纯遍历，适合统计类任务（如数if语句个数） - 别试图给每个
ast.*Expr或ast.*Stmt单独写Visit方法——Go 没泛型重载，你会写一堆重复的if node, ok := n.(*ast.CallExpr); ok { ... }
如何用 ast.Inspect 实现带状态的 AST 遍历？
多数代码分析需求要跨节点维护上下文，比如记录当前函数名、是否在循环体内、变量作用域层级。这时候不能只靠闭包变量，得封装成结构体，把状态和遍历逻辑绑在一起。
示例：提取所有函数调用的函数名（不含方法调用）：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type CallVisitor struct {
Calls []string
}
func (v *CallVisitor) Visit(n ast.Node) ast.Visitor {
if call, ok := n.(*ast.CallExpr); ok {
if ident, ok := call.Fun.(*ast.Ident); ok {
v.Calls = append(v.Calls, ident.Name)
}
}
return v // 继续遍历
}
// 使用：
fset := token.NewFileSet()
f, _ := parser.ParseFile(fset, "main.go", src, 0)
v := &CallVisitor{}
ast.Inspect(f, v.Visit)
- 必须返回
v（而非nil）才能继续遍历；返回nil表示终止当前分支 - 不要在
Visit里修改正在遍历的 AST 节点——ast.Inspect不保证线程安全，且修改后可能影响后续判断 - 如果需区分进入/退出节点（如进函数时 push scope，出函数时 pop），
ast.Inspect不支持；此时该用ast.Walk+ 自定义Walk函数，或改用golang.org/x/tools/go/ast/inspector
golang.org/x/tools/go/ast/inspector 比标准库 ast 强在哪？
它专为静态分析设计，支持按节点类型批量匹配、跳过特定子树、复用 inspector 实例——比手写 Inspect 回调更清晰，尤其适合多规则并行扫描。
示例：检查是否有未使用的变量声明（简化版）：
insp := inspector.New([]*ast.File{f})
insp.Preorder([]*ast.Node{(*ast.AssignStmt)(nil)}, func(n ast.Node) {
stmt := n.(*ast.AssignStmt)
if stmt.Tok == token.DEFINE {
for _, l := range stmt.Lhs {
if ident, ok := l.(*ast.Ident); ok && !isUsed(ident.Name, f) {
fmt.Printf("unused var %s\n", ident.Name)
}
}
}
})
- 类型匹配用
*ast.AssignStmt这样的指针类型，不是值类型；传nil是为了占位，实际匹配靠类型系统 -
Preorder在进入节点时触发，Postorder在退出时触发，能自然处理作用域嵌套 - 它不包含在标准库中，需
go get golang.org/x/tools/go/ast/inspector；Go 1.21+ 已稳定，但旧项目若锁死 Go 版本，可能遇到兼容问题
AST 遍历时最容易被忽略的边界情况
真实 Go 代码里，AST 结构比文档示例复杂得多。几个高频漏点：
-
ast.File的Decls可能含ast.GenDecl（import/var/const/type）、ast.FuncDecl、甚至ast.BadDecl（解析失败的碎片），不判空直接取.Specs会 panic - 函数参数和返回值是
ast.FieldList，其List字段可能为nil（比如func() {}） -
ast.Ident的Name可能是"_"（空白标识符），不是所有工具都正确跳过它 - 内联函数字面量（
func() {}）的ast.FuncLit没有Name，但它的Type.Params.List和Body.List同样要递归处理 - Go 1.22+ 支持泛型，
ast.TypeSpec的Type可能是*ast.IndexListExpr，老代码若只检查*ast.StructType会漏掉泛型类型定义
AST 分析不是写一次就完事的事——只要 Go 语言加语法，ast 节点类型就可能新增，而你的类型断言不会报错，只会静默跳过。每次升级 Go 版本后，至少扫一眼 go/doc 里 ast 包的变更日志。
