Go没有原生依赖树命令，go mod graph输出扁平有向边，gomodtree提供最接近树形的缩进视图，但依赖本地缓存且不反映实际构建时模块加载结果；go list -m all仅列模块不体现层级，go mod why -m只返回一条最短路径。
Go 没有原生的“依赖树”命令，go mod graph 输出的是扁平有向边，gomodtree 是最接近树形结构的实用方案，但必须清楚它不等于编译时实际加载的模块集合。
go list -m all 只列模块，不体现层级
它输出所有模块（含间接依赖）的扁平列表，格式为 module/path v1.2.3，第一行是当前模块。关键点在于：
- 不展示谁依赖谁，只告诉你“这个模块在依赖图里存在”
-
go list -m（不加all）只会返回当前模块名，容易误以为没输出 - 执行必须在含
go.mod的目录下，否则报错no modules found - 若用了
replace，比如replace github.com/foo/bar => ./local，输出仍显示原始路径和版本，但实际编译用的是本地路径 - 它不解析条件构建（如
//go:build !windows），只反映go.mod静态声明
go mod graph 输出的是“谁 import 了谁”，不是树
每行 A B@v1.2.3 表示模块 A 直接 import 了模块 B，箭头方向是 A → B。常见误读和实操要点：
- 右边才是被依赖方，不是“B 被 A 引用”的反向理解
- 输出包含所有
go.sum记录的 module 关系，包括仅在*_test.go中使用的模块，这些不会进入最终二进制 - 想看主模块的直接依赖：运行
go mod graph | grep "^$(go list -m) " | cut -d' ' -f2 - 查某模块被谁拉进来（反向依赖）：需用
go mod graph | awk '{print $2}' | grep 'target-module'再人工回溯，或配合go mod why -m - 重复版本（如
github.com/some/lib@v1.0.0和@v1.1.0）会各占一行，这是版本冲突的直接信号
gomodtree 是目前最可用的树形视图，但有缓存依赖
它输出缩进结构，类似 tree 命令，能直观看到嵌套层级和 (indirect) / (replace) 标记：
立即学习“go语言免费学习笔记（深入）”；
- 安装命令是
go install github.com/icholy/gomodtree@latest（注意不是 loic-lopez 版本，后者已归档） - 默认从当前模块展开；可指定目标模块：
gomodtree github.com/your-org/app - 它依赖本地
go.sum和模块缓存，CI 环境刚拉代码未执行go mod download时，部分间接依赖可能缺失 - 输出中同一模块出现在多个分支（如
golang.org/x/sys被logrus和net同时引用）是正常现象，不代表错误 - 不支持过滤掉 test-only 模块，需手动结合
grep -v排除含-test、testutil等关键词的路径
go mod why -m 只给一条路径，不是全图
当你在 go list -m all 里看到一个陌生模块，又不确定谁引入的，go mod why -m 是唯一可靠手段，但它有明确局限：
- 输出的是从主模块出发的**一条最短路径**，例如
main → cobra → pflag → yaml.v2，不代表这是唯一路径 - 如果某模块被多个路径引入不同版本，它只显示其中一个，需结合
go mod graph | grep手动比对其他边 - 对
replace后的本地路径无效——go mod why -m ./local-fix会报错，得查原始模块名再执行 - 它不处理
replace或exclude的运行时效果，只按go.mod声明回溯 - 真正要确认某个构建用了什么版本，得看
go version -m your-binary，而不是任何静态分析命令
依赖树不是快照，而是构建上下文的产物；go build、go test 甚至 go run 都可能触发隐式模块加载，导致 go list -m all 和实际打包结果不一致——这点最容易被忽略。
