go mod graph 输出扁平有向边而非树形结构，每行表示“谁依赖谁”，如 github.com/user/app golang.org/x/net@v0.14.0；它不合并重复依赖、无层级缩进、不体现 indirect/replace、也不区分构建约束。
go mod graph 输出的是扁平依赖边，不是树
很多人误以为 go mod graph 能直接输出树形结构，其实它只输出“谁依赖谁”的有向边，每行形如 github.com/user/app golang.org/x/net@v0.14.0。这意味着：
- 同一个下游模块（如 golang.org/x/sys）可能被多个上游重复列出，但不会自动合并或缩进
- 没有层级缩进，看不出 A → B → C 这样的三级链路，只有 A → B 和 B → C 两条独立边
- 不区分直接/间接依赖，indirect 标记在输出里完全不体现
- 若项目用了 replace，图中仍显示原始模块路径（如 github.com/foo/bar@v1.0.0），而非本地路径 ./local
用 gomodtree 看真正带缩进的依赖树
gomodtree 是目前最接近“人眼可读依赖树”的命令行工具，它把 go mod graph 的边关系还原成缩进结构：
- 安装必须用 go install github.com/icholy/gomodtree@latest（注意不是已归档的 loic-lopez 版本）
- 默认从当前 module 展开，支持指定模块名：例如 gomodtree github.com/your/app
- 显示 (indirect) 和 (replace) 标记，一眼识别非直接引入或被替换的模块
- 依赖本地 go.sum 和模块缓存，CI 环境首次构建时若没执行过 go mod download，部分间接依赖会缺失
- 输出中重复子树（如多个路径都引入 golang.org/x/sys）会分别展开，不自动折叠
go mod why -m 只给一条最短路径，不是全链
当你在 go list -m all 里看到一个陌生模块，想确认“谁把它拉进来的”，go mod why -m gopkg.in/yaml.v2 返回的是**第一条可达路径**，例如：
maingithub.com/spf13/cobragithub.com/spf13/pflaggopkg.in/yaml.v2
但要注意：
- 它不保证覆盖所有引用路径，尤其当模块被多个不同路径引入时
- 如果某模块被 replace 成本地路径，go mod why -m ./local-fix 会报错，得查原始模块名再试
- 它不处理构建约束（//go:build !windows），哪怕该依赖实际不会参与编译，只要在 go.mod 里声明了就会被追踪
- 配合 go mod graph | grep 'yaml.v2' 才能发现其他潜在路径
依赖链深度影响实际构建行为，不能只看静态声明
Go 的依赖解析基于最小版本选择（MVS），而 go mod graph 和 gomodtree 都只反映 go.mod 声明的静态关系：
- 实际编译时，_test.go、/internal/test、/testdata 目录下的 import 不会影响主模块依赖树，但 go mod graph 仍会包含它们
- 构建 tag 控制的条件性 import（如 //go:build darwin）在图中无体现，但决定最终打包内容
- go list -deps 和 go mod graph 结果常不一致：前者按当前可 build 的 package 计算，后者按整个 go.sum 记录的 module 关系
- 深度超过 5 层的依赖链容易引发版本冲突，这时要优先检查中间层模块是否锁定了过于严格的版本（比如硬 require v1.0.0 而非 ^1.0.0）
