go mod graph 输出的是模块级有向边集合，每行形如“A B@v1.2.3”表示A依赖B的指定版本；它不是树形结构，不区分直接/间接依赖，也不过滤构建约束，仅反映go.sum中记录的原始依赖快照。
go mod graph 输出的是什么，不是什么
go mod graph 输出的是模块级的有向边集合，每行形如 github.com/user/app golang.org/x/text@v0.14.0，表示前者直接或间接依赖后者。它不输出树形结构，不区分直接/间接依赖，也不过滤构建约束（比如 //go:build !windows 的依赖仍会出现在结果里）。你看到的只是 go.sum 中所有已解析模块之间的原始依赖关系快照，和当前代码是否 import 无关——哪怕某个模块在 go list -deps 里根本没出现，只要它被记录在 go.sum 里，go mod graph 就会把它列出来。
怎么快速定位某个模块是谁引入的
想查 gopkg.in/yaml.v2 是谁带进来的？别只靠 grep 正向扫，容易漏掉中间跳转。先用 go mod graph | grep 'gopkg.in/yaml.v2@' 拿到所有指向它的边，再用 awk '{print $1}' 提取上游模块；如果结果太多，加一层 go mod why -m gopkg.in/yaml.v2 看最短路径——但注意：go mod why 只返回一条路径，且对 replace 后的本地路径无效，得查原始模块名。
-
go mod graph | grep 'gopkg.in/yaml.v2@' | awk '{print $1}' | sort -u—— 列出所有直接或间接拉入它的模块 -
go mod why -m gopkg.in/yaml.v2—— 查一条可到达路径，适合快速验证是否真被主模块需要 - 若输出含
(indirect)，说明该模块未被主模块直接 require，而是由其他依赖传导进来
可视化依赖图时最容易翻车的三个点
用 go mod graph | dot -Tpng -o deps.png 生成图，看着很酷，但实际用起来常卡在三处：
- 默认布局会重叠：Graphviz 的
dot引擎在节点多时自动压缩，文字挤成一团；改用fdp或加-Gsplines=ortho能缓解，但无法自动折叠重复子树（比如多个模块都依赖golang.org/x/sys，图里会出现多份） - 版本号干扰可读性：直接喂给
dot会导致节点名过长；必须先用sed 's/@[^ ]*//g'去掉版本号，否则渲染失败或溢出边界 - CI 环境跑不通：刚 clone 的 repo 若没执行过
go mod download，go mod graph可能缺部分间接依赖（尤其replace指向本地路径时），导致图不全
gomodtree 和 go mod graph 不是替代关系，是分工关系
gomodtree 的价值不在“更漂亮”，而在“层级可读”。它把扁平的依赖边组织成缩进树，一眼能看出哪个模块引入了哪个版本的 golang.org/x/net，以及是否被多次引入（同一模块下出现两次相同子节点，大概率有版本冲突）。但它依赖本地模块缓存，刚拉代码没 go mod download 过，树就可能断层；而 go mod graph 不管缓存，只要 go.sum 里有记录，就一定输出。所以真实排查流程通常是：go mod graph 扫全局边 → gomodtree 看主模块树形结构 → go list -m all 核对实际生效版本 → 最后用 go mod why 验证可疑路径。
立即学习“go语言免费学习笔记（深入）”；
真正难搞的从来不是命令本身，而是 replace 和 exclude 在不同命令里表现不一致：它们在 go mod graph 里完全不生效，但在 go build 时又切实起作用——这意味着你看到的图，和最终编译时实际加载的模块，可能根本不是一回事。
