应先用 os.ReadFile 读取源码字符串，再调用 ast.ParseFile(fset, “”, src, parser.ParseComments)，并严格检查 err；fset 必须非 nil，否则 Pos() 返回 0。
怎么用 ast.ParseFile 读取 Go 源文件而不 panic
直接调用 ast.ParseFile 很容易因路径、模式或错误处理不当导致 panic 或返回 nil。它不自动处理不存在的文件、非 UTF-8 编码、或语法错误——这些都会让 ast.File 为 nil，而错误被丢在 err 里。
- 必须传入绝对路径或确保
src参数是有效字符串（比如用os.ReadFile先读内容，再用ast.ParseFile(fset, "", src, mode)） -
mode推荐用parser.ParseComments，否则注释节点全丢，后续做文档提取或标记就失效 - 别忽略
fset *token.FileSet：它是所有位置信息的源头，漏了会导致node.Pos()返回 0，无法定位代码位置 - 常见错误现象：
panic: runtime error: invalid memory address，大概率是没检查err != nil就直接访问file
遍历 AST 时为什么 ast.Inspect 比手写递归更稳
ast.Inspect 是标准库封装好的深度优先遍历，它自动跳过 nil 子节点、正确处理字段顺序、且支持中途退出（返回 false）。手写递归容易漏字段（比如忘记看 FuncType.Params 里的 FieldList），或在嵌套深时栈溢出。
- 函数签名是
func(node ast.Node) bool，返回false表示“别往下走了”，适合提前终止（如只找第一个main函数） - 不要在回调里修改 node 字段——AST 是只读结构，改了也没用，还可能干扰后续遍历逻辑
- 想获取父节点？
ast.Inspect不提供，得自己维护栈；若需要，改用ast.Walk配合自定义Visitor实现 - 性能影响：无显著开销，但避免在回调里做 heavy I/O 或正则匹配，会拖慢整个分析
识别函数定义时，*ast.FuncDecl 和 *ast.FuncLit 别搞混
前者是顶层函数声明（func foo() {}），后者是闭包字面量（go func() {}() 或赋值给变量的匿名函数）。两者结构相似，但所属上下文和生命周期完全不同，静态分析目标也不同。
-
*ast.FuncDecl的Name.Name是函数名，Recv非 nil 表示是方法；*ast.FuncLit的Name永远是 nil - 使用场景差异：查导出函数用
FuncDecl；分析 goroutine 泄漏或 defer 嵌套，得重点抓FuncLit - 容易踩的坑：用
ast.Inspect匹配*ast.FuncDecl时，如果没加类型断言保护，遇到FuncLit会静默跳过——因为类型不匹配，不会进回调 - 参数差异：
FuncLit没有Doc字段（注释属于外层语句），而FuncDecl的Doc是*ast.CommentGroup，可直接提取
为什么 go/ast 不能直接拿到变量真实类型
go/ast 只负责语法层面，不执行类型检查。你看到的 *ast.Ident 或 *ast.StarExpr 只是“长得像指针”或“叫 x”，不是“x 的类型是 *http.Client”。真类型得靠 go/types 配合 ast.Node 和 token.Position 查表。
立即学习 “go 语言免费学习笔记（深入）”；
- 常见错误现象：想判断某个
ast.Expr是否是error类型，直接看.Name——结果连 interface 都没解析，更别说底层实现 - 正确路径：先用
ast.ParseFile+types.NewPackage构建类型信息，再通过info.TypeOf(node)获取types.Type - 兼容性影响：引入
go/types后编译变慢、内存占用翻倍，CI 中跑大规模分析要预留资源；本地调试建议加-gcflags="-m"看逃逸 - 简单替代方案：对固定模式（如
err != nil）可用字符串匹配 +ast.BinaryExpr判断，但不可靠，仅限原型验证
AST 节点本身没类型，只有形状；想让它“知道”自己是什么，得喂给类型系统。这点最容易被刚接触静态分析的人忽略——以为 parse 完就能查类型，结果一路 nil 到底。
