parser.parsefile仅做语法解析，不校验路径、构建约束或作用域；需手动检查err和f是否为nil，新建token.fileset，分层判空提取包名函数名，并启用parsecomments处理注释。
parser.ParseFile 不是“解析函数”，它只是语法树入口；真正拆解函数逻辑，得靠手动遍历 *ast.FuncDecl 节点并逐层检查字段——否则你拿到的只是壳，不是结构。
为什么直接取 f.Decls 会 panic
因为 f.Decls 可能为 nil：空文件、仅含注释、package 声明缺失、或解析中途出错但 err == nil（parser.ErrorList 静默收集）。更危险的是，即使 f.Decls 非空，里面也混着 *ast.GenDecl（变量/常量）、*ast.FuncDecl（函数）、*ast.TypeSpec（类型）等不同节点。
必须显式做类型断言和判空：
- 先确认
f != nil && f.Decls != nil - 对每个
decl做if fd, ok := decl.(*ast.FuncDecl); ok - 再检查
fd.Name != nil && fd.Recv == nil—— 过滤掉方法（Recv非空）和匿名函数（Name为nil）
FuncDecl 的参数与返回值怎么安全读取
fd.Type.Params 和 fd.Type.Results 是 *ast.FieldList 类型，它们的 List 字段可能为 nil（不是空切片），直接遍历 List 必 panic。常见错误是写成 for _, f := range fd.Type.Params.List。
正确做法是分两步判空：
- 检查
fd.Type.Params != nil，再检查fd.Type.Params.List != nil - 同理处理
fd.Type.Results - 参数名在
field.Names，但field.Names也可能为nil（如func(int)这种无名参数）
为什么 ParseComments 模式不能省
不传 parser.ParseComments，f.Comments 永远是 nil，哪怕源码里写满 //go:generate 或 // @router。Swag、golint、go vet 等工具全靠这个字段提取元信息。
而且注释位置绑定在 token.FileSet 上——如果复用 *token.FileSet 或路径没注册对，CommentGroup.Pos() 会指向乱码偏移，后续匹配注释和函数就完全脱节。
务必组合使用：
mode := parser.ParseComments | parser.AllErrors-
fset.AddFile(filename, -1, len(src))中filename必须是绝对路径 - 注释内容在
f.Comments，但需自己按位置匹配到对应*ast.FuncDecl
最易被忽略的一点：函数体（fd.Body）内部的嵌套 func 字面量不会出现在 f.Decls 里，它们属于语句层级；想抓全部函数定义，得用 ast.Inspect 配合类型判断，但要小心别把 go func(){}() 这类启动协程的也误当顶层函数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
