错误定位应直接使用err.(*parser.Error).Pos.Line和.Column，而非fset.Position()；解析失败时AST不可靠，须先检查err!=nil再处理。
parser.ParseFile 返回 nil 或 panic 时，怎么知道错在哪一行
根本原因是 parser.ParseFile 遇到语法错误时，不会直接把错误位置塞进返回的 *ast.File 里；它要么返回部分 AST（err != nil 但 f != nil），要么直接 panic（比如传了非法 UTF-8 或空 src）。你得靠 err 自己定位。
典型错误现象：panic: interface conversion: ast.Node is nil, not *ast.FuncDecl —— 这基本等于你没检查 err != nil 就直接用了 f；或者 f == nil 却还去遍历 f.Decls。
- 必须先判断
err != nil，再决定是否继续处理f -
err类型是error，但实际常为*parser.Error或parser.Errors，可类型断言后取.Pos -
err.(*parser.Error).Pos是token.Position，含Filename、Line、Column，不是token.Pos整数，不用过fset.Position()转换 - 若用
parser.AllErrors模式，err可能是parser.Errors（切片），需遍历每个*parser.Error
为什么 fset.Position(err.Pos()) 返回空或 panic
fset.Position() 依赖 token.Pos 值有效且被 fset 记录过。但 parser.Error.Pos 是独立构造的 token.Position，不是从 fset 分配的 token.Pos，所以不能传给 fset.Position()。
常见误操作：fset.Position(err.(*parser.Error).Pos) → panic 或空字符串，因为类型不匹配。
立即学习“go语言免费学习笔记（深入）”；
-
err.(*parser.Error).Pos已是最终可用的行列信息，直接用.Line和.Column - 只有
ast.Node.Pos()返回的才是token.Pos，才需要fset.Position()转换 - 如果想统一打印格式，就自己拼：
fmt.Printf("%s:%d:%d: %v", errPos.Filename, errPos.Line, errPos.Column, err)
解析失败时 AST 里还有没有“半成品”节点
有，但不可靠。Go parser 在 parser.AllErrors 模式下会尽力恢复，可能返回带部分声明的 *ast.File，比如 import 正确但函数体缺右括号，f.Decls 可能包含前面的 var 声明，但后面函数节点是 nil。
- 别假设
f.Decls非空就安全：要逐个判decl != nil再类型断言 -
*ast.FuncDecl的Body字段在语法错误时极易为nil（如func f() {没闭合） - 函数参数列表
f.Type.Params、返回值f.Type.Results同样可能为nil，不能直接 .List - 若需稳定提取结构，建议只处理
err == nil的情况；否则仅用err定位，不依赖 AST 内容
怎么让错误位置更准，比如指向缺失的逗号或多余的分号
Go parser 的错误位置通常是它“卡住”的地方，不一定是问题根源。比如 type T struct { X int Y string } 缺少逗号，错误位置标在 Y 开头，而非 int 后面。
- 错误行号一般靠谱，列号有时偏左（parser 回溯后报告第一个可疑 token）
- 加
parser.AllErrors能拿到多个错误，比默认模式更全，但不一定更准 - 不要依赖 AST 节点位置反推语法错误：节点本身可能根本没生成（如整个
struct块因错误被跳过） - 真实调试建议：用
go build直接编译原文件，它的错误提示和位置通常比手写 parser 更稳
err 本身的 token.Position。所有试图从 f 里挖位置的尝试，都建立在解析成功的前提下；一旦失败，f 就是残缺的，别强求它说话。 
