安全解析需用 token.NewFileSet()、parser.ParseComments 模式并检查 *ast.File 是否为 nil；精准改写函数体应走“解析→AST 修改→go/format 重写文件”流程，修改后必须 format.Node 写回磁盘才能生效。
怎么用 go/parser 安全解析 Go 源文件而不崩溃
直接调用 parser.ParseFile 很容易 panic，尤其遇到语法错误、缺失依赖或非标准包路径时。它默认不宽容，一有风吹草动就扔 panic: parse error。
真正安全的做法是显式传入 parser.Mode 并捕获错误：
- 加
parser.ParseComments才能拿到注释节点（否则ast.CommentGroup全是 nil） - 用
token.NewFileSet()作为第一个参数，所有后续操作（如格式化、定位）都依赖它，别复用或漏传 - 务必检查返回的
*ast.File是否为 nil —— 解析失败时它就是 nil，不是空结构体 - 如果源码来自字符串（比如模板生成），用
parser.ParseFile(fset, "dummy.go", src, 0)，文件名必须带扩展名，否则go/format可能报invalid format: no file name
怎么在 AST 上精准改写某个函数体，又不破坏原有缩进和注释
AST 是结构树，不是文本。直接改 funcDecl.Body 里的 ast.Stmt 列表，不会自动同步缩进或保留原位置的空行和注释——它们藏在 ast.File.Comments 里，和语句节点是分离的。
想“无感”修改，得绕开纯 AST 操作，走「解析 → 修改 AST → 用 go/format 重写整个文件」这条路：
立即学习“go语言免费学习笔记（深入）”；
- 不要手动拼接字符串替换；
go/format.Node会按官方风格重排，但前提是你的 AST 修改合法（比如没漏掉End()或错位Pos()） - 若只改一个函数，先用
ast.Inspect找到目标*ast.FuncDecl，再用ast.Copy深拷贝其Body，避免意外污染原树 - 注意：修改后如果新增了变量，要确保导入了对应包，否则
go build会报undefined: xxx—— AST 层不校验符号可见性
go/ast 里哪些字段改了会影响 go fmt 输出结果
不是所有字段都影响格式化结果，但几个关键位置一动，go/format 就会“察觉”并重排：
-
ast.Field.Names：字段名列表为空（如匿名字段*T）时，go fmt会输出T；若填了Names: []*ast.Ident{{Name: "_"}}，就会变成_ *T—— 看似微小，实则语义不同 -
ast.BasicLit.Kind：设成token.STRING还是token.RUNE，决定输出是"x"还是'x' -
ast.CallExpr.Lparen和Rparen的位置值（token.Pos）会影响括号换行策略；设成token.NoPos可能导致格式器强行展开多行调用 - 最隐蔽的坑：
ast.File.Package必须是真实包名整数（fset.Position(file.Package).Line要能查到），否则go/format.Node可能 panic 报invalid position
为什么改完 AST 后 go run 报错说找不到函数，但 go build 却成功
典型症状：你用 ast.Inspect 找到了 *ast.FuncDecl，改了名字或签名，保存后 go build 没报错，但 go run main.go 运行时报 undefined: MyFunc。
根本原因不是 AST 改错了，而是你没更新对应的 token.FileSet 中的源码缓存：
-
go run是边解析边执行，它读的是磁盘原始文件；你用 AST 修改后若没调用format.Node写回文件，磁盘内容根本没变 -
go build成功，只是说明 AST 结构合法、能编译通过，并不代表你改的代码已落地 - 正确流程：AST 修改 →
format.Node(fset, node)获取新字节 → 写入原文件（或新路径）→ 再go run - 别依赖
ast.Print查看效果，它输出的是调试树，不是可执行 Go 代码
