应使用go/format.Node将AST节点转为格式化Go源码字符串，因其可读性强；而fmt.Printf("%+v")仅输出内存地址和不可见私有字段，ast.Print则信息冗余难追踪。
用 go/format.Node 打印可读的 Go 代码结构
直接打印 *ast.File 或任意节点（比如 fmt.Printf("%+v", node)）只会输出内存地址和未导出字段，几乎不可读。真正能看清结构的方式是用 go/format.Node 把 AST 转回格式化后的 Go 源码字符串——它本质上是“反解析”，但对调试和理解结构极其有效。
关键点：
-
fset必须非 nil 且与解析时用的是同一个*token.FileSet，否则位置信息错乱，甚至 panic -
go/format.Node不会修改 AST，只读；但它要求节点结构合法（比如ast.File.Imports是[]*ast.ImportSpec，不能为 nil） - 若想打印单个函数或结构体，可把该节点传进去，不一定要传整个
*ast.File
示例：打印一个函数声明
fset := token.NewFileSet()
f, _ := parser.ParseFile(fset, "", `package main; func Hello() { println("x") }`, 0)
for _, d := range f.Decls {
if fn, ok := d.(*ast.FuncDecl); ok {
var buf bytes.Buffer
_ = format.Node(&buf, fset, fn) // ← 这里传 fn，不是 f
fmt.Println(buf.String())
}
}
ast.Print 适合快速看树形轮廓，但输出冗长
ast.Print 是标准库自带的调试工具，输出类似 Lisp 的嵌套结构，字段名+值全展开，适合确认某个字段是否存在、是否为 nil，但不适合人眼追踪逻辑流。
立即学习“go语言免费学习笔记（深入）”；
它不要求 fset，也不依赖格式化规则，所以比 format.Node 更“轻”，但代价是信息过载：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个节点都带完整类型名（如
*ast.FuncDecl）、所有字段（包括未设置的 nil 字段） - 注释、位置信息、作用域字段全打出来，实际分析时往往要手动过滤
- 对空文件或语法错误恢复后的部分 AST 也照打，不会 panic，但可能看到大量
<nil>
用法很简单：
ast.Print(fset, f) // f 是 *ast.File
为什么 fmt.Printf("%v") 和 fmt.Printf("%+v") 不推荐
Go 的 fmt 包对 AST 节点的默认输出是“黑盒式”的：
-
%v只显示类型名 + 地址（如&{0xc000102000}），完全看不出内容 -
%+v会打出所有字段，但私有字段（如ast.File内部的scope、comments等）不可见，且顺序混乱，无法对应文档描述的字段语义 - 更麻烦的是：很多字段是接口类型（如
ast.Node），fmt无法展开其具体实现，只显示接口值本身
换句话说，它不提供 AST 的“结构视角”，只提供运行时内存快照，对分析毫无帮助。
打印前必须检查的三个 panic 触发点
无论用哪种打印方式，只要 AST 来源没处理好，一执行就崩：
-
fset == nil：所有format.Node和ast.Print都会 panic，因为位置信息缺失 -
f == nil：parser.ParseFile返回 err 时，f可能为 nil，直接传给打印函数必 panic -
node == nil：比如遍历时没判空就传fn.Type.Params（它可能是 nil），而format.Node对 nil 节点不做防护
安全写法永远是：
if f != nil {
ast.Print(fset, f)
}
// 或
if fn.Type.Params != nil {
format.Node(&buf, fset, fn.Type.Params)
}
最常被忽略的是：即使 err == nil，AST 里依然遍布 nil 字段（FuncDecl.Doc、Field.Names、InterfaceType.Methods……），它们不是“空切片”，而是字面量 nil，解引用即崩。打印只是暴露问题的第一步，防崩才是日常。
