不能只靠go mod graph生成可用拓扑图，因其输出扁平有向边、无层级缩进、不处理replace和构建约束；需组合go list -m all、go mod why -m、gomodtree及graphviz过滤渲染。
不能只靠 go mod graph 直接生成可用的拓扑图——它输出的是扁平有向边，没有层级、无版本语义、不处理 replace 和构建约束，直接喂给 Graphviz 很容易得到一团乱线。
用 go mod graph 提取原始依赖边但必须过滤和清洗
它每行输出形如 github.com/user/app github.com/sirupsen/logrus@v1.9.0，表示“前者依赖后者指定版本”。但注意三点：
- 它包含所有间接依赖，动辄上千行，建议先用
grep限定范围：比如只看主模块直接依赖，运行go mod graph | grep "^$(go list -m) " | cut -d' ' -f2 -
replace不生效——即使你在go.mod里写了replace github.com/foo/bar => ./local，go mod graph仍输出原始远程路径和版本 - 它不区分“谁引入了谁”，想查反向依赖（比如
gopkg.in/yaml.v2被谁拉进来），得配合go mod why -m gopkg.in/yaml.v2，但它只返回一条最短路径，不是全量
用 gomodtree 看带缩进的树形结构，更贴近人脑理解
这是目前命令行下最接近“依赖树”直觉的工具，能标出 (indirect)、(replace)，还能反映嵌套层级：
- 安装：
go install github.com/icholy/gomodtree@latest（注意不是 loic-lopez 版本，后者已归档） - 运行：
gomodtree默认从当前 module 展开；加参数如gomodtree github.com/your/app可指定目标模块 - 它依赖本地
go.sum和模块缓存——CI 环境刚拉代码没执行过go mod download，可能漏掉部分间接依赖
导出为 DOT 格式再用 Graphviz 渲染，但默认布局会糊成一团
go mod graph | dot -Tpng -o deps.png 能出图，但实际交付时大概率失败：
- Graphviz 默认
dot引擎在节点超 50 个后极易重叠、交叉、挤成黑块；改用fdp或neato引擎更合适，例如：go mod graph | fdp -Tpng -o deps.png - 加
-Gsplines=ortho可让连线走正交路径，减少视觉干扰，但无法自动折叠重复子树（比如多个模块都依赖golang.org/x/sys） - 若只想看某几个关键模块的关系，别全量导出，先用
awk或sed过滤边，再喂给 Graphviz
真正稳定可交付的方案是组合使用 + 明确边界
没人靠单条命令生成“完美拓扑图”，工程中可靠做法是：
- 用
go list -m all列出所有模块及版本，作为“事实清单” - 用
go mod why -m $PKG定位可疑依赖来源，确认是否冗余或可替换 - 用
gomodtree快速扫视结构，发现重复引入或版本冲突（比如两个不同版本的zap同时存在） - 可视化仅用于阶段性沟通——比如发给新同事看整体轮廓，或在 PR 描述里附一张简化图；不要把它当运行时权威，它不反映构建时动态行为（如
//go:build ignore会直接让包消失）
复杂点在于：依赖图不是静态快照，而是随 GOOS/GOARCH、构建 tag、replace 规则实时变化的。你看到的图，永远只是当前环境、当前配置下的一个切片。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
