用 ast.Inspect 找 TypeAssertExpr 节点需启用 parser.AllErrors 模式并传入 token.FileSet，否则节点被裁剪或位置为空；其 X 和 Type 字段分别对应断言左右操作数，判空后可安全访问。
怎么用 ast.Inspect 找到所有 x.(T) 节点
直接遍历 *ast.TypeAssertExpr 节点即可 —— Go 的 AST 中，类型断言语句（如 v.(string)）被统一表示为该类型节点，不是靠字符串匹配或正则硬找。
关键点：必须启用完整解析模式，否则 TypeAssertExpr 可能根本不会出现在 AST 中。
-
parser.ParseFile第三个参数mode至少要包含parser.AllErrors，否则语法错误会中断解析，漏掉后续节点 - 别漏传
token.FileSet，否则位置信息为空，你连哪行写了断言都定位不到 -
TypeAssertExpr的X字段是左操作数（如v），Type字段是右操作数（如string），两者都可能为nil，但实际中极少；访问前仍建议判空
为什么 ast.Inspect 回调里常找不到 TypeAssertExpr
90% 是因为解析时没设对 mode —— 默认模式下，parser 会跳过部分表达式结构以加速，TypeAssertExpr 就在被裁剪之列。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须显式传
parser.Mode(0)或至少含parser.AllErrors，不能依赖零值 - 如果源码来自字符串（非文件路径），第四个参数要传源码内容，并加
parser.FromFile模式，否则 parser 会误判为无内容 -
TypeAssertExpr不会出现在函数体外（如全局变量初始化表达式中），但它会出现在*ast.FuncLit、*ast.CompositeLit等嵌套表达式内部，ast.Inspect能自动钻进去，不用手动递归
TypeAssertExpr 和 errors.As 怎么区分
AST 层面只认语法结构，不理解语义 —— errors.As(err, &t) 是普通函数调用，对应 *ast.CallExpr，和 TypeAssertExpr 完全无关。想同时抓“类型断言 + 错误包装检测”，得注册两个节点类型。
立即学习“go语言免费学习笔记（深入）”；
- 查类型断言：
[]ast.Node{(*ast.TypeAssertExpr)(nil)}（用inspector）或回调里写if _, ok := node.(*ast.TypeAssertExpr); ok { ... } - 查
errors.As：if call, ok := node.(*ast.CallExpr); ok { if ident, ok := call.Fun.(*ast.Ident); ok && ident.Name == "As" { ... } }，再往上溯包名是否为"errors" - 注意：
err.(*os.PathError)是TypeAssertExpr，而errors.As(err, &p)是CallExpr，二者 AST 节点类型不同，不能混用同一判断逻辑
用 inspector 加速多规则扫描
如果你不止找类型断言，还要顺带统计 if err != nil、提取注释、检查 panic 调用，别反复调 ast.Inspect —— 每次都 DFS 整棵树，性能浪费严重。
- 改用
golang.org/x/tools/go/ast/inspector，初始化一次inspector.New([]*ast.File{f}) - 用
insp.Nodes([]ast.Node{(*ast.TypeAssertExpr)(nil)}, func(n ast.Node) { ... })精准命中，跳过所有无关节点 - 注意：
inspector要求 Go 1.21+ 工具链，旧版本会 panic；若需兼容，坚持用ast.Inspect+ 显式类型判断更稳
, ok :=），只反映语法结构；是否带布尔检查，得看父节点是不是 *ast.AssignStmt 且 tok == token.DEFINE，这个要额外向上追溯。 
