parser.ParseFile不能直接解析代码片段，因其要求合法package声明，否则返回nil并panic；应改用parser.ParseExpr、parser.ParseStmt等细粒度函数，并注意位置信息丢失和错误处理。
直接用 parser.ParseFile 解析单个代码片段是错的——它默认按“完整 Go 文件”语义加载，缺失 package 声明或顶层结构时会 panic 或返回 nil，根本进不到遍历逻辑。
为什么 parser.ParseFile 不能直接解析片段
它不是“解析任意 Go 语法”的通用接口，而是为文件级上下文设计的：必须有合法 package 声明（哪怕只是 package main），否则 parser.ParseFile(fset, "", src, mode) 在遇到无 package 的片段（如 func hello() {}）时，err 不为 nil，f 为 nil，后续所有操作都崩。
- 传空字符串
""作文件名时，src必须是非 nil 字符串，且内容需满足 Go 源码基本结构 - 即使加了
parser.AllErrors，也不代表能容忍“无 package”，它只容忍语法错误（如少括号），不解决结构性缺失 -
f.Decls是顶层声明列表，但无package就没有合法Decls，连空切片都不会给你
正确做法：用 parser.ParseExpr 或 parser.ParseStmt
针对纯表达式（如 a + b）、单条语句（如 return x）或函数体片段（如 { x := 1; println(x) }），应跳过 ParseFile，改用更细粒度的解析函数：
-
parser.ParseExpr(src)：只解析一个表达式，返回ast.Expr；适合提取len(m)、strings.TrimSpace(s)这类子表达式 -
parser.ParseStmt(src)：解析单条语句，返回ast.Stmt；适合处理if x > 0 { ... }、for i := range s { ... } -
parser.ParseFile(fset, "", "package main\n"+src, mode)是 hack 方案，仅限你确定片段本身不含package且愿意强加一层包装——但会污染 AST 位置信息，且无法处理含import的片段
如何安全提取函数体内的变量名或调用链
比如你有一段字符串 s := "hello"; fmt.Println(s)，想找出所有被赋值的变量名和调用的函数名。别先 parse 成 *ast.File，而应：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
parser.ParseStmt分别解析每行（需按分号或换行拆分），或把整段当复合语句用parser.ParseStmt("{ "+src+" }")包裹成*ast.BlockStmt - 对得到的
*ast.BlockStmt调用ast.Inspect，类型断言*ast.AssignStmt找左值（stmt.Lhs[0].(*ast.Ident).Name），断言*ast.CallExpr找函数名（call.Fun.(*ast.Ident).Name或call.Fun.(*ast.SelectorExpr).Sel.Name） - 注意
call.Fun可能是*ast.Ident（如println）、*ast.SelectorExpr（如fmt.Println）或*ast.ParenExpr（如(f)()），不做类型判断直接取.Name必 panic
最容易被忽略的点：位置信息失效与错误处理
用 ParseExpr 或 ParseStmt 返回的节点，其 Pos() 和 End() 是 dummy 值（通常为 0），无法映射回原始字符串位置——如果你需要高亮错误或生成 patch，必须自己维护偏移量映射表。
另外，这些函数返回 err 时，node 总是 nil，绝不能在未检查 err != nil 前就对 node 做任何操作；常见错误是写成 expr, _ := parser.ParseExpr(src)，然后直接 ast.Inspect(expr, ...)，一旦解析失败，expr 是 nil，Inspect 内部会 panic。
