ast.Inspect 遍历需先判空再访问 Params/Results，init 函数名特殊，返回 false 可提前退出，节点只读不可修改；它比手写递归更全、更稳、不栈溢出。
怎么用 ast.Inspect 安全遍历函数声明
直接调用 ast.Inspect 是最常用也最容易出错的方式。它不自动跳过 nil 字段，也不帮你判空，一不留神就 panic。
常见错误是直接访问 funcDecl.Type.Params.List 或 funcDecl.Type.Results.List，但 Go 允许无参数、无返回值函数，此时 Params 和 Results 都是 nil，不是空切片。
- 必须先判断：
if funcDecl.Type.Params != nil才能遍历Params.List -
funcDecl.Name.Name == "init"表示是 init 函数，没有导出名，别当成普通函数处理 - 想提前退出（比如只找第一个
main），在回调里返回false；返回true才继续往下走 - 别在回调里改
node字段——AST 节点是只读副本，改了无效，还可能干扰遍历顺序
为什么 ast.Inspect 比手写递归更可靠
手写递归遍历 AST 看似自由，实则极易漏节点。比如只遍历 FuncDecl.Type.Params，却忘了 FuncType.Results 也是 *ast.FieldList 类型；或忽略 GenDecl 里嵌套的 FuncLit（匿名函数）。
ast.Inspect 内部已按 Go 语法规范完整覆盖所有字段路径，自动跳过 nil 子节点，且保证深度优先顺序稳定。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 它不会因嵌套过深导致栈溢出（标准库做了迭代优化）
- 字段访问顺序与 AST 定义一致，比如先
FuncType.Func再FuncType.Params，和 parser 输出严格对齐 - 如果你需要“在进入某个函数前记录作用域”，
ast.Inspect不提供父节点，得自己维护栈；这时别硬扛，换ast.Walk+ 自定义Visitor
什么时候该换用 inspector 而不是 ast.Inspect
当你要对同一组 AST 文件做多次不同目的的遍历（比如先找未使用变量，再统计函数复杂度，再提取注释），ast.Inspect 就成了性能瓶颈——每次都要重新 DFS 整棵树。
golang.org/x/tools/go/ast/inspector 在初始化时一次性构建事件列表，后续遍历直接扫描索引，实测快 2.5 倍。
- 初始化：用
inspector.New([]*ast.File{f1, f2})，不是单个文件 - 只查函数？传
[]ast.Node{(*ast.FuncDecl)(nil)}给Preorder，避免无谓节点访问 - 需要前后序逻辑（比如进函数时计数、出函数时汇总），用
Nodes方法，它比Preorder多一层控制粒度 - 注意：
inspector不兼容老版本 Go 工具链，Go 1.21+ 更稳；低于此版本建议 stick withast.Inspect
解析失败时为什么没报错，或者只报一个错就停了
parser.ParseFile 默认行为很“温柔”：遇到第一个语法错误就返回，err != nil，但不会告诉你还有多少错；不设 parser.AllErrors，它甚至不会收集第二个错误。
另一个隐形陷阱是注释——默认不解析注释，FuncDecl.Doc 和 FuncDecl.Comments 都为空，除非显式传 parser.ParseComments。
- 务必加 mode：
parser.ParseFile(fset, filename, nil, parser.ParseComments|parser.AllErrors) - 第四个参数传
nil表示从磁盘读文件；想内存解析（比如从 git blob 读），传源码字符串 +parser.FromFile模式 - 跨包分析函数调用关系？
go/ast不管语义，得接go/types做类型检查，否则连fmt.Println是哪个包的都分不清
真正难的不是遍历节点，而是理解哪些字段在什么条件下为 nil、哪些信息必须靠组合多个 AST 节点才能还原（比如方法接收者类型藏在 FuncDecl.Recv，而接收者名字又在 FieldList.List[0].Names 里）。别指望一次 parse 就拿到全部上下文。
