go list -m all 是最直接查看完整模块依赖列表的方式，输出当前模块及所有间接依赖的名称和版本，需在含 go.mod 的目录执行，加 -f 可定制格式，支持 replace/exclude 但不解析条件性 require。
用 go list -m all 查看完整模块依赖列表
这是最直接、无额外工具依赖的方式，输出当前模块及其所有间接依赖的名称和版本。它不展示层级关系，但能快速确认是否引入了某个特定模块（比如 golang.org/x/net）以及其确切版本。
常见误操作是只运行 go list -m（不加 all），结果只返回当前模块名；也有人在非 module 根目录下执行，导致报错 no modules found —— 必须确保在包含 go.mod 的目录中运行。
- 加
-f '{{.Path}} {{.Version}}'可定制输出格式，方便 grep 筛选 - 若项目使用 replace 或 exclude，
go list -m all仍会显示原始依赖路径，但实际编译时已被替换或忽略 - 该命令不解析
require的条件性（如// +build ignore影响的 import），仅反映go.mod声明的静态依赖
用 go mod graph 输出有向依赖图
go mod graph 输出的是“谁依赖谁”的边列表，每行形如 A B@v1.2.3，表示模块 A 直接 import 了 B 的该版本。它是构建可视化依赖树的基础数据源，也是排查重复引入、版本冲突的第一手线索。
典型问题：输出过长难以人工阅读；不同模块可能指向同一依赖的不同版本（如 github.com/sirupsen/logrus v1.8.1 和 v1.9.0 同时存在），这时需结合 go mod why 追溯来源。
立即学习“go语言免费学习笔记（深入）”；
- 配合
grep快速定位：例如go mod graph | grep 'golang.org/x/text' - 注意它不处理
indirect标记的模块——这些模块虽未被直接 require，但因被其他依赖引用而保留在go.mod中 - 输出不含版本号的行（如
A B）表示 B 是主模块或本地 replace 模块，此时需查go.mod中的replace声明
用 go mod why 追查某个包为何被引入
当你发现一个陌生模块出现在 go list -m all 或 go mod graph 中，又不确定是谁拉进来的，go mod why -m example.com/pkg 就是唯一可靠手段。它从主模块出发，沿着 import 链向上回溯，给出最短路径解释。
容易忽略的是：默认只显示一条路径，而实际可能存在多条引入路径（尤其当多个依赖都用了同一个底层库时）。若要检查全部路径，得手动换参数重试，比如先查 A → B，再查 C → B。
- 必须指定
-m参数才能查模块级依赖；不加则查具体包路径（如go mod why github.com/gorilla/mux） - 如果输出
main表示该模块被当前项目直接 require；若出现(root)则说明它来自replace或go.mod的顶层声明 - 对
indirect模块，go mod why仍能工作，但路径中会包含中间依赖的版本号，需对照go.sum确认一致性
依赖树可视化需借助外部工具
Go 官方不提供图形化依赖树，go mod graph 的文本输出需要转换。较常用的是 gomodviz（需 go install github.com/loov/gomodviz@latest），它把 go mod graph 结果转成 DOT 格式，再用 Graphviz 渲染为 PNG 或 SVG。
真正麻烦的是：一旦项目依赖超过百个模块，生成的图极易重叠、难定位。这时候不如放弃全图，改用分层过滤 —— 比如先用 go mod graph | awk '{print $2}' | sort | uniq -c | sort -nr 找出被最多模块引用的“枢纽包”，再针对它们单独调用 go mod why。
-
gomodviz -s可折叠标准库节点，减少干扰 - 某些私有模块路径含特殊字符（如
@、空格），gomodviz可能解析失败，此时应先用go mod graph | sed 's/ /_/g'预处理 - CI 环境中避免渲染图片，可改用
gomodviz -o deps.json输出结构化 JSON，供后续脚本分析
go get、go mod tidy 或升级某个依赖，都可能改变整个结构。真正关键的不是画出多漂亮的图，而是理解哪个 require 条目触发了某次间接升级，以及 go.sum 中对应 checksum 是否被重新计算。 
