go/parser 仅解析语法树，不处理导入、类型推导或构建约束；需配合 go/token 和 go/ast 手动遍历 ast 提取包名（f.name.name）和顶层函数名（过滤 *ast.funcdecl 且 func.recv 为空），并注意文件路径、编码、注释模式及测试文件后缀等细节。
go/parser 不能直接读文件获取包名或函数列表——它只做语法树解析，不处理导入、类型推导或作用域分析；想拿到包名、函数名这些信息，得配合 go/token、go/ast 手动遍历节点，而且必须注意文件是否在 $GOROOT 或 $GOPATH 之外、是否含 //go:build 约束、是否被 _test.go 后缀干扰。
怎么用 go/parser 安全加载单个 .go 文件
直接调用 parser.ParseFile 很容易 panic 或漏掉包名，因为默认不校验文件路径合法性，也不处理构建约束。正确做法是先构造 *token.FileSet，再显式传入源码字节（而非文件路径），避免隐式读盘和编码问题：
- 永远用
token.NewFileSet()创建新*token.FileSet，别复用全局或缓存的 - 用
os.ReadFile读取内容后传给parser.ParseFile的src参数，而不是传文件路径字符串 - 必须设
mode参数为parser.ParseComments，否则注释节点为空，后续无法识别//go:generate等指令 - 若文件含
package main但无func main()，解析成功但 AST 里不会报错——这属于语义检查范畴，go/parser不管
从 AST 中提取包名和顶层函数名的可靠方式
包名在 *ast.File 的 Name.Name 字段，但这个值可能为 "main" 即使文件实际属于其他模块；函数名则需遍历 File.Decls，过滤出 *ast.FuncDecl 类型并检查 Func.Name.Name。常见错误是忽略匿名函数、方法接收者、或把 init 当普通函数处理：
- 包名应优先取
f.Name.Name，但若文件是xxx_test.go，且测试包名是xxx_test，则真实包逻辑仍属xxx——需结合文件名后缀判断 - 函数名提取时跳过
if f.Name == nil的情况（如func() {}匿名函数） -
func (T) M()是方法，不是函数；其Func.Recv非空，Func.Name.Name是"M"，但不属于“包级函数列表” - 不要依赖
ast.Inspect全局遍历——它会进入函数体内部，误抓到局部func字面量
go/parser 在模块外或 vendor 下解析失败的典型原因
错误信息常为 "no package found" 或 nil *ast.File 返回，根本原因是 go/parser 完全不理解 Go modules、vendor 机制或 go.work，它只认绝对路径 + token.FileSet 映射。当文件来自 vendor/ 或非 GOPATH 路径时，必须手动补全 Filename 字段，并确保 token.FileSet.AddFile 的路径与 AST 节点中记录的一致：
- 调用
fset.AddFile(filename, -1, len(src))时，filename必须是完整路径（如/home/u/proj/vendor/x/y/z.go），不能是相对路径 - 若源码来自网络或内存（如
go:embed），filename可设为任意唯一字符串（如"<embedded>"</embedded>），但所有相关 AST 操作必须保持一致 -
//go:build ignore或// +build ignore注释会让go/parser直接跳过该文件——它不解析构建约束，只是按规则静默丢弃 - Windows 下路径分隔符混用（
\vs/）会导致token.Position显示异常，建议统一用filepath.ToSlash标准化
真正麻烦的是跨文件分析：一个函数调用另一个包的函数，go/parser 解不出那个函数在哪定义——它没符号表。这时候要么切到 golang.org/x/tools/go/packages，要么接受“只能看当前文件”的边界。很多人卡在这一步，以为 AST 能自动关联所有引用，其实不能。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
