最快方式是用parser.parsefile解析得*ast.file后调用ast.print打印树形结构；需传正确文件名、设token.newfileset、检查错误并加fmt.printf("ast:\n")提示。
用 go/ast + go/parser 解析并打印 AST 节点
直接看 AST 最快的方式不是靠 IDE 插件，而是写几行 Go 代码解析源文件并输出结构。核心是 go/parser.ParseFile 读取文件得到 *ast.File，再用 ast.Print 打印树形结构。
常见错误：传入路径时用了相对路径但没设置 srcDir，导致解析失败；或忘了 import "go/ast" 和 "go/parser"。
- 确保工作目录下有要分析的 Go 文件，比如
main.go - 代码中调用
parser.ParseFile时，第二个参数传文件名（如"main.go"），第三个参数设为nil或指定token.NewFileSet() - 打印前先调用
fmt.Printf("AST: ")，否则输出没有提示，容易误以为没结果
package main
import (
"fmt"
"go/ast"
"go/parser"
"go/token"
)
func main() {
fset := token.NewFileSet()
f, err := parser.ParseFile(fset, "main.go", nil, 0)
if err != nil {
panic(err)
}
fmt.Printf("AST:
")
ast.Print(fset, f)
}
用 ast.Inspect 遍历特定节点类型
如果只想看 FuncDecl、CallExpr 或 Ident 这类具体节点，ast.Inspect 比手动递归更可靠。它按深度优先遍历整棵树，回调函数接收每个节点指针。
容易踩的坑：回调函数里对节点做类型断言时，没加 != nil 判断就直接访问字段，panic；或者在遍历时修改了子节点（比如替换 Ident.Name），但没返回新节点，导致后续遍历出错。
- 回调函数签名必须是
func(node ast.Node) bool，返回true继续遍历子节点，false跳过 - 类型断言后务必检查是否为
nil，例如：if call, ok := node.(*ast.CallExpr); ok && call != nil { ... } - 想跳过某个子树（比如不进注释或字符串字面量），在对应节点类型分支里返回
false
调试时快速定位某段代码对应的 AST 节点位置
光看树形输出很难和源码行号对应上。关键是要结合 token.FileSet——它记录了每个节点的 Pos() 和 End()，能转成文件名、行号、列号。
性能影响不大，但频繁调用 fset.Position(pos) 会轻微拖慢遍历；如果只关心某几处，建议先用 ast.Print 粗略定位，再针对性查位置。
- 在
ast.Inspect回调里拿到节点后，用fset.Position(node.Pos())获取起始位置 - 注意：
node.Pos()是 token 的起始位置，不是节点“视觉上”的开头（比如if x {的node.Pos()指向if关键字） - 打印时加
fmt.Printf("%s:%d:%d: %T ", pos.Filename, pos.Line, pos.Column, node)，信息最实用
为什么不用 go tool compile -S 或 gobuild -gcflags="-S"
那些命令输出的是 SSA 或汇编，不是 AST。AST 是语法解析后的中间表示，在类型检查前，比 SSA 更贴近源码结构。想确认某个表达式是否被识别为 BinaryExpr，或函数参数怎么拆成 FieldList，必须走 go/ast 路线。
兼容性方面，go/ast API 在 Go 1.0 后基本稳定，但节点字段名可能微调（比如 Go 1.19 把 ast.CompositeLit.Elts 改名为 Elts，实际没变；真正要注意的是 ast.IndexListExpr 这类新增节点）。查文档时以你本地 go version 对应的 pkg.go.dev/go/ast 为准。
最常被忽略的是：ast.Print 默认只展开一层子节点，深层结构会被缩成 (...)。真要看全，得自己写递归打印逻辑，或临时改用 spew.Dump ——不过那会把 token.Pos 这种非导出字段也打出来，干扰判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
