直接用go/parser解析源码会panic，常见原因是src参数为nil、文件不存在且未传合法字符串源码、未初始化token.FileSet导致Pos()失效、未设置parser.ParseComments致注释为空，以及忽略error后强行访问nil节点。
为什么直接用 go/parser 解析源码会 panic？
常见原因是传入了非法路径或空内容，go/parser.ParseFile 要求 src 参数非 nil，且文件必须存在（除非显式传入 src 字符串）。更隐蔽的问题是：没设置 mode，导致注释、位置信息丢失，后续遍历时 ast.CommentGroup 为空或 node.Pos() 返回 token.NoPos。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终用
parser.ParseFile(fset, filename, src, parser.ParseComments)，不要省略parser.ParseComments -
*token.FileSet必须初始化，它是所有位置信息的源头：fset := token.NewFileSet() - 若解析字符串而非文件，
filename可填任意非空名（如"dummy.go"），src传[]byte("func main() {}") - 检查返回 error，不要忽略 —— 即使语法合法，
import路径错误也会在这里报错
如何安全遍历 AST 并提取函数名和参数列表？
别直接断言 node.(*ast.FuncDecl)，AST 节点类型多，强制转换易 panic。应该用 ast.Inspect 配合类型判断，或继承 ast.Visitor 接口。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
ast.Inspect最简：遇到*ast.FuncDecl就处理，其余跳过 - 函数名取
decl.Name.Name，但注意decl.Name可能为 nil（如匿名函数） - 参数列表在
decl.Type.Params.List，每个元素是*ast.Field；字段名（形参名）是field.Names（可能为空切片），类型是field.Type - 想获取类型名？对
field.Type做类型断言：t, ok := field.Type.(*ast.Ident)，但多数情况是*ast.StarExpr或*ast.SelectorExpr，需递归判断
go/ast 和 go/types 解析结果有什么本质区别？
go/ast 只做语法树构建，不校验语义 —— 它能解析 var x int = y，哪怕 y 未定义；而 go/types 需要完整包加载和类型检查，才能告诉你 y 是 undeclared name。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 仅做代码格式分析、结构统计、简单重构（如批量改函数名），用
go/ast足够 - 要做“这个变量实际是什么类型”“这个方法是否实现了某接口”，必须上
go/types.Check，代价是慢、依赖go/build或golang.org/x/tools/go/packages - 二者可共存：
go/types的Info结构里有Types和Defs映射，键是ast.Node，所以先用ast.Inspect找到节点，再查info.Types[node].Type
为什么修改 AST 后格式化输出总是丢失换行和缩进？
go/ast 不保存空白符信息，它只存语法结构。调用 format.Node 输出时，会按默认规则重排 —— 这不是 bug，是设计如此。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要试图从
*ast.File恢复原始格式；如需保留格式，用gofmt或go/format对生成的字符串再处理 - 修改 AST 后写回文件，推荐：先用
printer.Fprint输出到bytes.Buffer，再用gofmt.Source格式化字节流 - 若要精准控制（如只替换某段代码），别改 AST，改用
go/token.FileSet.Position定位起止偏移，直接操作源码字节
AST 解析真正难的不是遍历，而是搞清哪些信息它根本不管 —— 比如作用域、变量生命周期、常量折叠结果。这些得靠 go/types 或手动模拟，别指望 go/ast 给你答案。
