go mod graph 输出每行“a@v1.2.3 b@v0.5.0”表示 a 直接依赖 b，右侧为被 import 模块；它包含全部 go.sum 中 module 关系（含 indirect 和 test-only），不区分构建约束，也不标版本冲突，需结合 grep、awk、go list -deps 和 go mod why 等命令交叉分析。
go mod graph 输出结果怎么看
它输出的是纯文本有向图，每行 a@v1.2.3 b@v0.5.0 表示「a 依赖 b」，不是「b 被 a 引用」的反向关系。很多人第一眼以为箭头朝右是“被依赖”，其实正好相反——右边那个才是被左边直接 import 的模块。
常见错误现象：go mod graph | grep some-module 只能查到直接依赖，漏掉间接路径；想看某模块被谁拉进来，得用 go mod graph | awk '{print $2}' | grep some-module 再反推。
- 依赖层级不体现深度，同一行只表达一级引用，嵌套关系要靠多轮 grep + awk 拼接
- 重复版本会出现多次，比如
github.com/some/lib@v1.0.0和github.com/some/lib@v1.1.0是两条独立边 - 没有去重，同一个依赖对在不同构建 tag 下可能重复出现（比如加了
//go:build ignore的文件不影响 graph，但条件编译的 import 会影响）
怎么过滤出关键路径（比如排除 test-only 依赖）
go mod graph 默认包含所有依赖，包括仅在 *_test.go 文件里 import 的模块。这些在最终二进制里不会被打包，但会干扰分析主干依赖链。
实操建议：先用 go list -f '{{join .Deps "\n"}}' ./... 获取非测试代码的真实依赖列表，再和 go mod graph 做交集；更简单的方法是加个临时约束：
立即学习“go语言免费学习笔记（深入）”；
go mod graph | grep -v '/internal/test\|_test\.go\|/testdata' | grep 'your-target-module'
- 不能只靠文件名过滤，有些项目把测试工具放
tools/目录且被主模块 import，得结合go list -m all看实际 module 名是否含-test或testutil类关键词 -
go mod graph不区分构建约束，如果某依赖只在//go:build !windows下生效，它仍会出现在输出里
为什么 go mod graph 和 go list -deps 结果不一致
根本区别在于作用域：go list -deps 是按当前目录下可 build 的 package 计算依赖，而 go mod graph 是整个 go.sum 里记录的所有 module 关系，不管它们是否被当前代码 import。
典型场景：执行过 go get github.com/foo/bar 但没在任何 .go 文件里 import，go mod graph 仍会显示它，go list -deps 则完全看不到。
-
go list -deps受当前GOPATH、GOOS/GOARCH和 build tag 影响，go mod graph完全无视这些 -
go list -deps不展示 indirect 标记的模块（除非真被引用），go mod graph会照常输出所有边 - 性能上，
go mod graph快得多，因为它不加载 AST，只读go.mod和go.sum
可视化依赖树时容易忽略的版本冲突点
go mod graph 本身不标出版本冲突，但它输出的重复模块名+不同版本，就是冲突线索。比如同时看到：
main@none github.com/gorilla/mux@v1.8.0<br>main@none github.com/gorilla/mux@v1.7.4
说明有两个路径分别拉了不同版本，Go 会按最小版本选择器（MVS）选一个，但另一个可能因 replace 或 exclude 被强制降级——这时候 graph 里看不出哪条边被 override 了。
- 必须配合
go mod graph | grep 'github.com/gorilla/mux@'+go mod why github.com/gorilla/mux交叉验证 - 如果某模块在 graph 中出现但
go list -m github.com/x/y显示indirect，说明它没被主模块直引，而是某个依赖的依赖，这种最容易在升级时突然 break - Windows 路径分隔符在 graph 输出里是正斜杠，和 Linux/macOS 一致，不用额外转义
真正麻烦的不是画出树，而是确认每一行边是否还在生效——go mod graph 不告诉你某次 go get 后哪些边被缓存覆盖了，得手动 go mod tidy -v 看实际解析过程。
