go list -json 获取包依赖更可靠，因其经官方构建系统处理了 build tag、module mode、replace 等全部语义逻辑，而 AST 仅解析源码字面量，无法反映真实依赖。
用 go list -json 获取包依赖比直接解析 AST 更可靠
直接靠 ast 包分析 import 语句来推导依赖关系，容易漏掉条件编译、嵌套 vendor、replace 指令、test-only 导入（如 _ "net/http/pprof"）等场景。Go 官方构建系统自己都不靠 AST 做依赖解析，而是用 go list 的结构化输出——它已处理完所有 build tag、GOOS/GOARCH、module mode 切换等逻辑。
实操建议：
- 优先执行
go list -json -deps -f '{{.ImportPath}} {{.DepOnly}}' ./...，它返回的是 Go 构建器实际看到的依赖图，含主模块、间接依赖、测试依赖标记 - 若需区分“显式 import”和“仅被测试引用”，注意
.DepOnly字段：true 表示该包未被当前包的非-test 代码直接 import - 避免用
go list -f拼接字符串；必须加-json，否则字段缺失（比如.Module在非 JSON 模式下不输出）
ast.ImportSpec 只能提取源码字面量 import，不反映真实构建依赖
如果你确实需要从 .go 文件中读取 import 路径（例如做静态 lint、生成文档），ast 是可行的，但它只做词法/语法层面的提取，不做语义解析。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 把
import _ "C"当成普通包，实际是 cgo 标记，不应计入 Go 依赖 - 忽略
// +build !windows等 build tag，导致在非目标平台误判为依赖 - 无法识别
import "foo" // foo is github.com/x/y in go.mod这类 alias 或 module 重映射
最小可用示例（提取单个文件的 import 路径）：
file, err := parser.ParseFile(fset, "main.go", src, parser.ImportsOnly)
if err != nil {
log.Fatal(err)
}
for _, imp := range file.Imports {
path, _ := strconv.Unquote(imp.Path.Value) // 注意要 unquote
fmt.Println(path)
}
想构建完整依赖图？别手写 DFS 遍历 ast，用 golang.org/x/tools/go/packages
packages.Load 是官方推荐的、替代 ast + 手动路径拼接的方案。它内部调用 go list，但封装了 package-level 加载、类型检查、跨 module 解析能力，且支持 mode = packages.NeedDeps。
使用场景与要点：
- 当你要知道 “A.go import B，B 又 import C”，且 C 是本地 module 还是第三方，是否在
go.sum中——这时必须用packages.Load - 传入
Config.Mode = packages.NeedName | packages.NeedFiles | packages.NeedDeps，否则Pkg.Path和Pkg.Deps为空 - 注意
Pkg.Deps是 import path 字符串 slice，不是 *Package 指针；要获取依赖的详细信息，得再次调用packages.Load加载它们（或一次性加载整个 graph） - 性能影响：首次加载会触发
go list和 type check，后续复用Config可缓存结果
为什么 go mod graph 不适合程序化分析
go mod graph 输出的是 module 级依赖（如 github.com/a/b v1.2.0 github.com/c/d v0.5.0），不是 package 级。它无法告诉你 “main.go 里到底 import 了哪些包”，也不能反映 _ 导入、test-only 导入、或同一 module 内不同 package 之间的引用关系。
容易踩的坑：
- 把
go mod graph结果当作 AST 分析结果混用，导致误判循环依赖（module A 依赖 B，B 依赖 A，但实际 A 的某个 package 并没 import B 的任何 package） - 忽略
go mod graph不包含标准库路径（如fmt、net/http），而go list -deps会列出它们 - 没有处理重复边：同一个 module 依赖可能在输出中出现多次，需自行 dedupe
真正要落地的依赖分析工具，核心链路通常是：go list -json -deps → 解析 JSON → 按需补查 packages.Load 获取 AST 或类型信息。AST 本身只是中间材料，不是依赖事实的源头。
