Golang ast实现依赖分析的技巧-Golang-PHP中文网

直接遍历 ast.importspec 不够用，因其仅捕获显式 import 语句，漏掉隐式依赖：如点导入、别名引用、类型字面量中的包名（如 *http.client），以及未通过 import 声明但实际使用的跨包符号；准确依赖分析必须结合 go/packages 加载与 go/types.info.uses 映射，通过递归解析 ast.selectorexpr 获取 base ident 并查其所属包。

golang ast实现依赖分析的技巧

为什么直接遍历 `ast.ImportSpec` 不够用

只扫 Imports 字段只能拿到显式 import 语句，漏掉所有隐式依赖：比如 fmt.Println 调用来自 "fmt"，但若代码里写的是 import . "fmt" 或 import f "fmt"，ImportSpec.Path.Value 还是 "fmt"，可后续的 CallExpr.Fun 是 *ast.SelectorExpr，其 X 是 *ast.Ident，名字是 f 或空字符串，根本对不上包路径。

更麻烦的是跨包类型引用：比如 var x *http.Client，http 出现在类型字面量里，不在 Imports 列表中 —— 它属于 ast.StarExpr → ast.SelectorExpr → ast.Ident 链，必须向下钻到字段类型节点才能捕获。

显式 import 只覆盖 import 块，不反映实际符号使用位置
ast.Ident 出现在表达式、类型、函数参数等任意位置，都可能指向外部包
别假设 Ident.Name 就是包名：它可能是别名（f）、点导入（空字符串）或未限定标识符（需结合作用域判断）

如何从 `ast.Ident` 安全反查所属包

仅靠 go/ast 无法完成这件事 —— ast.Ident 本身不带包信息，它只是个名字和位置。你必须把 ast 和 go/types 结合，用 types.Info.Uses 映射。

典型流程是：先用 go/packages.Load 加载整个模块（不是单个文件），启用 packages.NeedTypesInfo；然后遍历每个 pkg.Syntax 中的 *ast.File，在 ast.Inspect 回调里对每个 *ast.Ident 查 pkg.TypesInfo.Uses[node]，如果返回非 nil 的 types.Object，再通过 obj.Pkg() 拿到所属包。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

不能对单个 os.ReadFile + parser.ParseFile 做这事：缺少类型检查上下文，Uses 为空
obj.Pkg() 返回 *types.Package，其 Path() 是导入路径（如 "net/http"），Name() 是本地包名（如 "http"）
注意过滤 obj.Pkg() == nil 的情况：说明是当前包内定义的标识符，不是依赖

`ast.SelectorExpr` 是依赖分析的关键跳板

绝大多数跨包调用和类型引用都落在 ast.SelectorExpr 上：左边是包名或接收者标识符，右边是导出名。但它的结构容易误读 —— X 不一定是 *ast.Ident，也可能是 *ast.SelectorExpr（如 foo.bar.baz），甚至 *ast.IndexExpr（极少见）。

安全提取方式是递归展开 X 直到得到最外层标识符，再查 types.Info.Uses：

func getBaseIdent(n ast.Node) *ast.Ident {
    switch x := n.(type) {
    case *ast.Ident:
        return x
    case *ast.SelectorExpr:
        return getBaseIdent(x.X)
    default:
        return nil
    }
}

别直接断言 n.(*ast.SelectorExpr).X.(*ast.Ident)：一遇到 pkg.Subpkg.Func 就 panic
ast.SelectorExpr.Sel 是方法或字段名，不参与依赖判定；真正决定依赖的是 getBaseIdent(expr.X) 的结果
如果 getBaseIdent 返回 nil，说明这个 selector 不指向包级符号（比如是 struct 字段访问 x.field），可跳过

为什么 `go/ast` 单独跑不出准确依赖图

因为 Go 的依赖不是语法层面的“写了 import 就算”，而是语义层面的“这个标识符最终解析到了哪个包”。没有 go/types 的类型检查，你就无法区分：

json.Marshal（来自 "encoding/json"）和 myjson.Marshal（当前包自定义函数）
time.Now()（来自 "time"）和 timer.Now()（某个叫 timer 的局部变量）
同名包导入：import json "encoding/json" 和 import json "github.com/my/json"，仅看 AST 无法知道 json.Marshal 绑定的是哪一个

真正可靠的依赖分析必须走 go/packages + go/types 流程，哪怕只是分析一个文件，也要把它作为 package 的一部分加载，否则 Uses 和 Defs 都是空的。这点最容易被忽略：很多人卡在“为什么 info.Uses 全是 nil”，答案往往是没用 packages.Load，而用了手工 parser.ParseFile。