Go types.Package.Imports 怎样生成包的直接依赖图

我最近把一个只读取 AST 的小工具改成类型分析工具，目标是输出“某个 Go 包依赖了哪些包”。真正省事的入口不是重新扫描所有 import 字符串，而是直接读取 *types.Package 的 Imports()。它返回当前包的直接导入包；再以 Path() 作为节点身份递归展开，就能得到一张稳定的依赖图。

官方地址：https://pkg.go.dev/go/types#Package

核心做法：把 Package.Imports() 当成一条条“直接依赖边”，用包路径去重，再决定是否继续展开下一层。不要把一次 Imports() 调用误当成完整传递依赖，也不要在需要源码事实时忽略 export data 的边界。

把 Imports 看成直接依赖边

go/types.Package.Imports() 的返回值是 []*types.Package，表示当前包直接导入的包，列表保持源码顺序。它适合做图的邻接表：当前包是一个节点，返回列表中的每个包就是一条出边的终点。为了让这个关系更直观，图1把根对象写成 root *types.Package，把返回值写成 source-order list，再连到每个 direct package。

第一次写时我差点直接把返回列表序列化成 JSON，结果只能看到一层。这个接口不会替你把 fmt 继续展开成它的依赖；传递依赖需要由调用方继续访问每个子包的 Imports()。

用包路径递归构建邻接表

图节点建议使用 Package.Path()，而不是包名。不同目录可能都叫 util，路径更适合作为稳定身份。下面的函数只接收已经完成类型检查的根包，输出“包路径到直接依赖路径”的邻接表。

package graph

import "go/types"

// BuildImportGraph 递归整理类型包的直接导入关系。
// key 使用包路径，避免同名包被错误合并；visited 只负责防重复遍历。
func BuildImportGraph(root *types.Package) map[string][]string {
	graph := make(map[string][]string)
	visited := make(map[string]bool)

	var visit func(*types.Package)
	visit = func(pkg *types.Package) {
		if pkg == nil {
			return
		}
		path := pkg.Path()
		if visited[path] {
			return
		}
		visited[path] = true

		imports := pkg.Imports()
		neighbors := make([]string, 0, len(imports))
		for _, dep := range imports {
			if dep == nil {
				continue
			}
			// 保留 Imports 的顺序，输出更容易和源码对照。
			neighbors = append(neighbors, dep.Path())
			visit(dep)
		}
		graph[path] = neighbors
	}

	visit(root)
	return graph
}

这里的 visited 不是为了判断 Go 包是否允许循环导入，而是为了避免共享依赖被重复展开。正常类型检查已经拒绝非法的包循环；图算法仍然应保留这个保护，因为同一个依赖可能从多个上游节点到达。

如果只想要一层，可以不递归 visit(dep)，直接把 root 的 neighbors 保存下来。若要输出完整图，则保留递归，并把每个包都写入 graph，哪怕它的邻接列表为空。

区分源码导入与 export data 结果

这是我改造工具时最容易忽略的一点。源码侧的 source files 中，显式导入可以通过 AST 的 ast.ImportSpec 得到，形成 explicit imports；而 Package.Imports() 是类型系统中的包关系。官方文档特别说明：如果包来自 export data，Imports() 可能包含为 package-level object 提供类型的包，因此它不一定等于源码文件里写出的 import 集合。最后的 dependency graph 应标注自己采用的是哪一种来源。

所以我现在按需求选数据源：

• 要回答“源码显式写了哪些 import”，遍历 ast.File.Decls 中的 GenDecl.Specs，读取 *ast.ImportSpec。
• 要回答“类型检查结果中当前包直接依赖哪些包”，使用 Package.Imports()。
• 要回答“完整传递依赖是什么”，从 Package.Imports() 递归展开，并用路径去重。

这三种结果都可以叫“依赖”，但语义不一样。把它们混在同一张报告里，后续排查缺包、生成许可证清单或分析类型引用时都会出现难以解释的差异。

回归检查与适用边界

我会给构图函数保留四个小检查点：根包为 nil 时返回空图；同名不同路径的包不能合并；同一个依赖从两个上游到达时只能展开一次；叶子包必须保留空邻接表。除此之外，还要在报告中注明数据来源是源码 AST 还是类型包，避免读者把两套集合当成严格相等。

对我来说，最实用的迁移顺序是：先保留原来的 AST 报告，再新增一份 types 图；确认两者的差异能够解释后，再决定哪一份作为默认输出。这样既能利用类型系统的包对象，也不会因为 export data 的来源变化而误解报告。

相关问题

Package.Imports 会自动包含所有传递依赖吗？

不会。它返回当前包的直接导入包；传递依赖需要递归访问子包的 Imports()。

为什么不直接用包名作为图节点？

包名不保证全局唯一，同名目录会发生冲突。使用 Path() 更适合作为节点身份。

什么时候必须回到 AST？

当问题是“源码中明确写了哪些 import”时，应读取 ast.ImportSpec；类型包结果可能受到 export data 语义影响。