应使用 switch node := node.(type) 进行类型判断，而非反射或字符串匹配；需先判 nil，再按具体类型如 ast.FuncDecl、ast.BasicLit 分支处理，并合理控制 ast.Inspect 的遍历深度。
如何用 ast.Kind 判断 Go AST 节点类型
Go 的 go/ast 包不提供类似 node.Kind() 这样的方法，节点类型判断只能靠类型断言或反射，最直接、最常用的方式是使用 switch node := node.(type) 结构。这不是“运行时类型 ID”，而是 Go 语言原生的接口类型匹配机制。
常见错误是试图访问不存在的字段（比如对 *ast.BasicLit 做 node.Name 访问），或在未确认类型前直接断言（如 node.(*ast.FuncDecl) 可能 panic）。
- 所有 AST 节点都实现了
ast.Node接口，但该接口只定义了Pos()和End()，不包含类型信息 - 必须用类型断言或
switch分支处理具体子类型，例如*ast.FuncDecl、*ast.ReturnStmt - 不要依赖
fmt.Sprintf("%T", node)做逻辑分支——它返回的是字符串，不可靠且性能差
为什么不能用 reflect.TypeOf(node).Name()
reflect.TypeOf(node).Name() 返回空字符串，因为几乎所有 AST 节点都是指针类型（如 *ast.CallExpr），而 reflect.Type.Name() 只对命名类型（非指针、非匿名结构体）有效；*ast.CallExpr 的底层类型名无法通过 Name() 获取。
- 正确做法是用
reflect.TypeOf(node).String()，它返回"*ast.CallExpr"这类完整字符串，但依然不推荐用于逻辑判断 - 反射慢、可读性差、无法被编译器检查，一旦 AST 结构微调（如内部重命名），反射字符串匹配就失效
- 标准库示例（如
go/format、gofmt）全部使用类型 switch，这是事实标准
ast.Inspect 遍历时怎么安全识别节点类型
ast.Inspect 的回调函数参数是 ast.Node，每次进入都需明确判断当前节点是否是你关心的类型。重点在于：提前 return 控制遍历深度，避免无谓递归；同时注意节点可能为 nil（如某些字段未设置）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
ast.Inspect(file, func(n ast.Node) bool {
if n == nil {
return true // 继续遍历
}
switch x := n.(type) {
case *ast.FuncDecl:
fmt.Printf("func %s\n", x.Name.Name)
return false // 不再进入该 FuncDecl 内部（可选）
case *ast.BasicLit:
if x.Kind == token.STRING {
fmt.Printf("string literal: %s\n", x.Value)
}
}
return true
})
-
return false表示跳过该节点的子节点遍历，适合只需顶层匹配的场景 -
return true表示继续深入，适用于需要检查嵌套结构（如函数体内所有return语句） - 务必先判
n == nil，否则n.(type)在 nil 接口上 panic
容易忽略的边界情况：类型别名与嵌套字段差异
AST 节点类型看似固定，但实际使用中常因字段嵌套层级或别名导致误判。例如 *ast.Ident 是标识符，但函数调用中的名字是 CallExpr.Fun 字段，它可能是 *ast.Ident，也可能是 *ast.SelectorExpr（如 pkg.Func）。
-
*ast.Field和*ast.FieldList容易混淆：前者是单个 struct 字段声明，后者是花括号内的字段集合 -
*ast.ValueSpec承载var x, y int中多个名字，但x和y都在Names字段里，不是独立节点 - 自定义类型别名（如
type MyInt int）在 AST 中表现为*ast.TypeSpec，但其Type字段是*ast.Ident，不是*ast.StructType
真正难的不是写对一个 switch，而是理解每个节点在语法树里的位置和上下文约束——多打印 go/ast.Print(fset, node) 看原始结构，比查文档更快。
