Golang ast实现类型识别的方法-Golang-PHP中文网

用 ast.inspect 遍历 ast 时，优先匹配 ast.typespec 提取命名类型，再递归检查字段、函数签名等位置的类型表达式（如 ast.structtype），并结合 obj.kind == ast.typ 区分标识符是否为类型。

golang ast实现类型识别的方法

如何用 `ast.Inspect` 遍历并识别 Go 源码中的类型节点

直接靠 ast.Inspect 走一遍 AST，遇到 *ast.TypeSpec 就提取类型名和底层类型，是最轻量、最可控的识别方式。它不依赖类型检查器（types.Info），适合做语法层扫描，比如生成文档、找未导出类型、统计类型定义位置。

常见错误是只匹配 *ast.TypeSpec 却忽略嵌套场景：比如 type Foo struct{ x int } 中的 struct{ x int } 本身也是类型，但不是 TypeSpec，而是 *ast.StructType —— 这类“匿名类型”得在字段、函数签名、变量声明里单独捕获。

用 ast.Inspect 遍历时，优先判断节点是否为 *ast.TypeSpec（对应 type X Y 形式）
再递归检查 *ast.Field.Type、*ast.FuncType.Results、*ast.AssignStmt.Lhs 等位置的类型表达式
对 *ast.Ident 类型名，需结合其 Obj 判断是否为类型（obj.Kind == ast.Typ），避免把变量名当类型
注意 ast.StarExpr（指针）、ast.ArrayType（数组）、ast.MapType（映射）等复合类型节点需向下展开

`types.Info` 中怎么安全取 `types.Type` 并区分基础类型与自定义类型

如果需要知道某个标识符的真实类型（比如 var x time.Time 中 x 的完整类型），必须用 types.Info。但它不能直接“识别类型”，而是提供类型信息查询入口，关键在怎么查、查什么。

容易踩的坑是直接调 info.TypeOf(node) 却没校验返回值：它可能返回 nil（如未解析成功）、或返回 types.Invalid（如引用了未定义类型）。更隐蔽的是，types.Basic（如 int、string）和 types.Named（如 time.Time）结构完全不同，强行断言会 panic。

先用 info.TypeOf(expr) 获取 types.Type，再用 if t != nil && t != types.Typ[types.Invalid] 做空/无效防护
区分类型类别：用 t.Underlying() 可剥离命名类型得到底层（如 type MyInt int → int）；用 types.IsNamed(t) 判断是否为用户定义的命名类型
获取类型名：对 types.Named，用 t.(*types.Named).Obj().Name()；对 types.Basic，用 t.String()（如 "int"）
不要依赖 t.String() 做类型相等判断——它带包路径且格式不稳定；要用 types.Identical(t1, t2)

为什么 `ast.Expr` 不能直接转成 `types.Type`，以及怎么桥接二者

ast.Expr 是语法树上的表达式节点（如 *ast.Ident、*ast.SelectorExpr），而 types.Type 是类型检查器产出的语义类型对象，二者不在同一层。想从一个 ast.Ident 得到它代表的类型，必须通过 types.Info 查表，而不是 AST 自身转换。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

典型误操作是看到 ast.Ident.Name == "string" 就认为这是字符串类型——其实它可能是变量名、函数名、甚至包名。只有 info.Types[ident].Type 才能告诉你它在当前作用域中是否被用作类型。

桥接关键：拿到 *ast.Ident 后，查 info.Types[ident].Type；拿到 *ast.SelectorExpr（如 http.Header）后，查 info.Types[selector].Type
若查不到（info.Types 中无该 key），说明该节点未参与类型推导（如注释里的伪代码、未启用的构建标签分支）
对 *ast.CallExpr.Fun 这类可能既是函数调用又是类型转换的节点（如 int(x)），要先确认 info.Types[call.Fun].Type 是否为函数类型，再看是否属于类型转换语法

性能敏感场景下，避免重复解析和类型检查的实践要点

批量处理多个 Go 文件时，反复调 parser.ParseFile + types.Check 极易成为瓶颈。AST 解析本身快，但 types.Check 涉及符号表构建、依赖解析、方法集计算，开销大。

最容易被忽略的是：同一个包内多个文件共享一份 *types.Package，但很多人对每个文件都新建 types.Config 和 types.Info，导致相同导入包被重复检查。

单包多文件：复用同一个 *types.Config 和 types.Info，一次性传入所有 *ast.File 给 checker.Files
跨包分析：用 go/types.Importer 缓存已加载的包（如 types.DefaultImporter 已内置缓存），避免重复加载 stdlib 或第三方包
仅需语法识别时（如找 type X struct），跳过 types.Check，纯 ast.Inspect 足够，速度提升 5–10 倍
调试时加 config.Error 回调并计数，可快速发现因类型错误导致的大量 types.Invalid 泄漏