go/parser 解析失败不报错是因为默认返回 parser.errorlist 而非 panic，需显式检查 err != nil || len(errors.errors()) > 0；常见原因包括路径错误、go 版本不匹配、缺少 package 声明。
为什么 go/parser 解析失败却没报错？
默认情况下，go/parser.ParseFile 遇到语法错误会返回 nil 和一个 parser.ErrorList，但这个错误列表不会自动 panic 或打印——它安静地躺在返回值里，容易被忽略。
- 务必检查返回的
err是否为nil，否则可能拿到空*ast.File还浑然不觉 - 更稳妥的做法是显式检查
err != nil || len(errors.Errors()) > 0，其中errors是parser.ErrorList - 常见静默失败场景：文件路径拼错、Go 版本不匹配（如用 Go 1.21 解析含泛型别名的 Go 1.22 代码）、缺少
package声明
ast.Inspect 遍历时如何安全获取函数体和参数？
ast.Inspect 是深度优先遍历，但节点类型杂、嵌套深，直接断言易 panic。关键不是“怎么走”，而是“走到哪才真正有你需要的结构”。
- 函数声明必须先确认是
*ast.FuncDecl，再取f.Type.Params.List（参数）和f.Body.List（语句） -
f.Type.Params.List中每个元素是*ast.Field，其Names可能为空（匿名参数），Type才是真实类型节点 - 别在
ast.CallExpr里直接读Fun的*ast.Ident.Name——它可能是*ast.SelectorExpr（如fmt.Println），需递归解析
解析带 //go:build 或 // +build 的文件时 AST 不全？
go/parser 默认不处理构建约束（build constraints），它只做纯语法解析。如果源码顶部有构建标记，而你没传对应 mode，parser 会跳过整个文件或漏掉部分节点。
- 必须启用
parser.ParseComments（否则注释节点为空） - 若需按构建标签过滤，得自己预处理：用
go/build包判断是否应包含该文件，或传入src.Mode |= parser.ParseComments后手动扫描ast.File.Comments - 注意：
go/parser不理解go:build语义，它只把构建注释当普通*ast.CommentGroup，逻辑过滤得自己写
AST 节点修改后如何生成可运行的 Go 代码？
go/ast 是只读分析工具，改了节点 ≠ 改了源码。想落地修改，必须走 go/format + go/token 重建文件，中间差着词法层。
立即学习“go语言免费学习笔记（深入）”；
- 不要试图拼接字符串生成代码——缩进、括号、分号、导入顺序全会错
- 标准做法：用
token.NewFileSet()创建文件集 →parser.ParseFile()得到*ast.File→ 修改节点 →format.Node(w, fset, node)输出格式化后代码 - 特别注意：修改
ast.ImportSpec后，必须同步更新ast.File.Imports切片，且要保证ImportSpec.Path是带引号的字符串字面量（如"fmt"），否则format.Node会 panic
AST 分析最耗神的地方不在遍历逻辑，而在节点类型的嵌套判定和边界条件——比如 ast.Expr 可能是 *ast.BasicLit、*ast.Ident、*ast.BinaryExpr 中任意一种，每种取值方式都不同，漏判一个就 panic。别图省事用单个类型断言兜底。
