go mod graph 输出是机器可读的原始依赖边列表，需经过滤、加壳为graphviz格式并用dot等工具渲染才可可视化；直接人眼阅读或直接喂给dot会失败。
go mod graph 输出太长，根本没法看
直接跑 go mod graph 会吐出上千行文本，每行是 moduleA moduleB 这样的依赖指向，人眼完全无法识别结构。这不是设计缺陷，而是它本就定位为机器可读的中间格式——你得把它喂给图可视化工具，不能直接 human-read。
实操建议：
- 先用
go mod graph | head -20看前20行，确认输出正常（没报no required module provides package这类错误） - 过滤掉标准库和无关模块：用
go mod graph | grep -v "golang.org/" | grep -v "rsc.io/"（按需调整排除项） - 导出到文件再处理：
go mod graph > deps.dot，避免管道中断或缓冲问题
dot 命令生成 SVG 失败：command not found 或语法错误
go mod graph 输出不是合法的 Graphviz .dot 文件，缺头尾声明和格式包装，直接丢给 dot 必然报错。
实操建议：
- 加壳再转：用
echo "digraph G {" > deps.gv && go mod graph | sed 's/ / -> /' >> deps.gv && echo "}" >> deps.gv，生成合规.gv文件 - 确保已安装 Graphviz：
dot -V能输出版本；macOS 用brew install graphviz，Ubuntu 用apt install graphviz - 生成 SVG：运行
dot -Tsvg deps.gv -o deps.svg；若报too many nodes，加-Gsize="100,100!" -Gratio=fill控制画布
图里全是间接依赖，主模块关系被淹没
默认 go mod graph 包含所有 transitive 依赖，比如你的 github.com/user/app 可能只显式依赖 github.com/gin-gonic/gin，但图里还会塞进 gin → net/http → crypto/tls → …，真正关心的一级依赖反而看不见。
实操建议：
- 聚焦主模块：用
go list -f '{{join .Deps "\n"}}' ./...配合go list -m all手动比对，或改用go mod graph | awk '$1 ~ /^your-module-name/ {print}' - 用
gomodgraph工具替代原生命令：go install github.com/loov/gomodgraph@latest，然后跑gomodgraph -format=svg ./...，它默认折叠 stdlib 并高亮主模块 - 注意
replace和exclude不影响go mod graph输出，图中仍会显示被替换前的原始路径
生成的 SVG 打不开或节点重叠严重
Graphviz 默认用 dot 布局引擎，适合有向无环图，但 Go 模块依赖存在循环引用（如 a → b → c → a）时，dot 会强行破环+拉伸，导致边线交叉、节点挤成一团。
实操建议：
- 换布局引擎：
neato -Tsvg deps.gv -o deps.svg（适合稀疏图），或fdp -Tsvg deps.gv -o deps.svg（适合密集图） - 限制深度：先用
go list -deps -f '{{.Path}}' ./... | head -100截断依赖树深度，再基于这些模块子集生成图 - 浏览器打开 SVG 时若空白，检查是否含中文路径（Graphviz 对 UTF-8 支持不稳），临时改模块名为 ASCII 再试
真正麻烦的是跨平台构建场景：CI 中生成的图可能因本地 GOOS/GOARCH 影响 go list 结果，导致图和实际运行时依赖不一致。这点容易被忽略，但线上排障时很要命。
