gomodtree以缩进树形结构直观展示依赖关系，标出(indirect)和(replace)，但依赖本地模块缓存且不展开条件性require；go mod graph输出原始有向边，需grep过滤；go mod why -m仅返回一条最短引用链。
用 gomodtree 看缩进树形结构，最接近直觉
它输出类似 tree 命令的缩进格式，一眼能看清谁引入了谁、哪层是间接依赖、哪处用了 replace。安装后直接运行即可，不用额外参数：
go install github.com/icholy/gomodtree@latestgomodtree
注意两点：
• 它依赖本地模块缓存（go.sum 和 $GOPATH/pkg/mod），CI 环境刚拉代码没执行过 go mod download 时，部分间接依赖可能不显示
• 输出里会标出 (indirect) 和 (replace)，但不会展开条件性 require（比如 // +build ignore 控制的导入）
用 go mod graph 快速抓边，再 grep 过滤关键路径
go mod graph 输出的是原始有向边，每行 A B@v1.2.3 表示 A 直接依赖 B 的该版本。它不处理 replace 和 exclude，所以看到的仍是 go.mod 里的原始路径——这点容易误判本地替换是否生效。
常用过滤方式：
• 只看主模块的直接依赖：go mod graph | grep "^$(go list -m) " | cut -d' ' -f2
• 查某个模块被谁引入（反向依赖）：go mod graph | awk '{if ($2 ~ /golang.org\/x\/net@/) print $1}'
• 统计总边数（大致反映依赖复杂度）：go mod graph | wc -l
用 go mod why -m 追一条最短链，不是全路径
当你在 go list -m all 里看到一个陌生模块，又不确定谁带进来的，go mod why -m 是唯一能给出引用链的原生命令。但它只返回一条最短路径，不是所有路径。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
例如：go mod why -m gopkg.in/yaml.v2 可能输出：
# gopkg.in/yaml.v2<br> main<br> github.com/spf13/cobra<br> github.com/spf13/pflag<br> gopkg.in/yaml.v2
这意味着至少有一条路径经过这些模块。但如果该模块被多个上游以不同版本引入，这条链不能代表全部；此时得回过头用 go mod graph | grep 手动比对。
另外：go mod why -m ./local-fix 会失败，必须用原始模块名（如 github.com/foo/bar），哪怕你已在 go.mod 里写了 replace。
别信 PNG 图，go mod graph | dot 易踩布局坑
生成可视化图确实直观，但默认输出极易重叠、挤成一团，尤其依赖超过 50 个节点时。加 -Gsplines=ortho 或换引擎（fdp）能缓解，但无法自动折叠重复子树（比如多个模块都依赖 golang.org/x/sys，图里会重复画好几遍）。
真正有用的不是图本身，而是把 go mod graph 当作数据源喂给脚本处理——比如提取所有指向 golang.org/x/net 的上游，再逐个 go mod why -m 验证。
构建时实际用的模块，和 go list -m all 列出的未必一致；最终以 go version -m your-binary 输出的嵌入信息为准。
