go mod graph 输出依赖边集，每行格式为“依赖者→被依赖者@版本”，需用 sed 去版本号、awk 反查、dot 渲染或 go mod why 追因，方能定位冲突与冗余依赖。
直接用 go mod graph 就能拿到完整的依赖边列表，但它不是树形结构，也不是可视化图——它只是原始依赖关系的“边集”，必须配合其他工具才能看清层级、定位冲突或生成图像。
怎么快速看懂 go mod graph 的输出格式
每行是 依赖者 指向 被依赖者@版本，例如：
github.com/your/project@v0.0.0 github.com/sirupsen/logrus@v1.9.3 github.com/sirupsen/logrus@v1.9.3 golang.org/x/sys@v0.15.0
注意三点：
-
依赖者不一定是你的主模块，也可能是中间依赖（比如logrus本身又依赖x/sys） - 版本号带
@vX.Y.Z是精确引用，不同行出现同一模块多个版本，就说明存在版本冲突 - 它不区分直接/间接依赖——
go.mod里写的和传递引入的一起吐出来，没法一眼看出“谁是我显式要的”
查某个模块被谁引入（反向依赖分析）
这是最常踩坑的场景：你发现项目里莫名出现了 golang.org/x/tools，但 go.mod 里根本没写它。这时
- 错：
go mod graph | grep x/tools→ 可能漏掉带版本号的行，或匹配到路径子串（如tools/v2） - 对：
go mod graph | grep 'golang.org/x/tools@v0.18.0'→ 精确命中某版本被谁拉入 - 更稳：先用
go list -m all | grep x/tools看当前解析出的实际版本，再拿这个完整字符串去grep
如果要批量找所有引用了某模块的上游（即“谁依赖了我？”），得靠 awk 反向提取第一列：
go mod graph | awk '$2 ~ /golang\.org\/x\/tools@v0\.18\.0$/ {print $1}'生成可读的依赖图（DOT + Graphviz）
go mod graph 原生输出不能直接喂给 dot，因为 Graphviz 要求节点名不含 @vX.Y.Z，且需包一层 digraph 头尾。常见错误是直接管道过去却没处理版本号，导致渲染失败或节点名乱码：
- 必须先删版本号：
sed 's/@[^ ]*//g'（注意空格分隔，不能用cut -d@ -f1，会切错路径含@的模块） - 必须加
digraph包裹，否则dot报语法错：
echo "digraph Dependencies { rankdir=LR; node [shape=box];" > deps.dot
go mod graph | sed 's/@[^ ]*//g' | sed 's/^/"/; s/ /" -> "/; s/$/"/' >> deps.dot
echo "}" >> deps.dot
dot -Tpng deps.dot -o deps.png生成的图默认横向展开（rankdir=LR），适合宽屏查看；若节点太多糊成一团，说明项目依赖过深，该考虑拆包或约束间接依赖了。
配合 go mod why 定位具体引入路径
go mod graph 告诉你“谁依赖了谁”，但不告诉你“为什么我要它”。比如你看到 cloud.google.com/go@v0.114.0 出现在图里，但不确定是哪个业务模块拖进来的：
- 运行
go mod why -m cloud.google.com/go，它会从主模块出发，逐层打印一条最短依赖链 - 输出类似：
# cloud.google.com/go→your/project→github.com/aws/aws-sdk-go-v2/config→cloud.google.com/go，说明是 AWS SDK 的某个 transitive 依赖意外引入了 GCP SDK - 这时再回
go mod graph | grep cloud.google.com/go，就能验证是否还有其他路径，避免误判
真正难的不是画出依赖图，而是看懂图里哪条边不该存在——graph 是事实，why 是归因，两者缺一不可。
