不能。go list -m all仅输出扁平化模块列表，不展示依赖路径、版本冲突、replace/exclude效果，也无法定位某模块被谁引入；需用go mod graph或go list -deps配合其他命令分析。
go list -m all 能查出所有依赖版本吗
能，但默认只显示主模块和直接依赖的版本，间接依赖（即依赖的依赖）默认折叠。要展开完整树形结构，必须加 -deps 参数。不加的话，像 golang.org/x/net 这类被多个包共同引用的模块可能只出现一次，且版本号未必是你项目实际使用的那个。
常见错误是执行 go list -m all 后发现某个依赖版本“不对”——其实是它被更上层的依赖覆盖了，而 -deps 模式下才能看到真实解析结果。
- 查完整依赖树：
go list -m -deps all - 只看主模块和一级依赖：
go list -m -f '{{.Path}} {{.Version}}' all - 过滤特定模块（如找所有含
yaml的）：go list -m -deps all | grep yaml
go mod graph 输出的是什么格式
go mod graph 输出的是原始依赖边关系，每行形如 A B@v1.2.3，表示模块 A 依赖模块 B 的 v1.2.3 版本。它不经过版本裁剪（version elimination），所以会出现多个版本共存的情况，比如同一模块被不同路径引入了 v1.0.0 和 v1.5.0。
这个命令适合排查“为什么用了旧版”，但不适合直接读版本号——因为输出没有排序、没有去重，且不含主模块自身信息。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 配合
sort | uniq -c统计某模块被多少路径引用：go mod graph | awk '{print $2}' | sort | uniq -c | sort -nr - 查找某模块的所有上游依赖路径：用
go mod graph+grep -E配合反向追踪（需脚本辅助，原生命令不支持） - 注意：
go mod graph不显示replace或exclude生效后的实际版本，仅反映go.mod声明关系
go list -m -json 如何提取真实生效版本
go list -m -json 对每个模块返回结构化 JSON，其中 Version 字段是 Go 工具链最终选定的版本，已考虑 require、replace、exclude 和最小版本选择（MVS）规则。这是最权威的“实际生效版本”来源。
但要注意：不加 all 时只返回主模块；加 all 才返回全部——且此时 Version 是 MVS 计算后的结果，不是 go.mod 里写的原始版本。
- 查主模块版本：
go list -m -json - 查全部模块并提取路径+版本：
go list -m -json all | jq -r '.Path + " " + .Version' - 如果
.Replace字段非空，说明该模块已被替换，.Version是替换目标的版本，不是原始声明版本
为什么 go.mod 里的版本和实际构建用的不一致
因为 Go 使用最小版本选择（MVS），不是“锁死版本”。go.mod 中写的是最低要求（require A v1.2.0 表示“至少 v1.2.0”，不是“只能 v1.2.0”），最终选哪个版本取决于整个依赖图中所有 require 约束的交集。
典型场景：你的模块 require B v1.0.0，而 B 的作者在 v1.0.1 修复了 panic，你没升级自己的 go.mod，但另一个依赖 C require B v1.0.1，那么 MVS 就会选 v1.0.1 —— 此时 go list -m all 显示的是 v1.0.1，但你的 go.mod 里仍是 v1.0.0。
- 想锁定版本？运行
go get A@v1.2.0（显式指定）或go mod tidy（自动更新go.mod到当前解析结果） -
go.sum记录的是实际下载的 zip 校验值，它比go.mod更接近“真实用的版本” - 交叉验证建议：比对
go list -m -json all和go.sum中的模块名与版本，不一致说明本地缓存或网络拉取异常
go list -m -json all，但别忽略 go.sum 里记录的校验信息——它才是构建可重现性的底线。MVS 规则让版本看起来“不透明”，但恰恰是它避免了 diamond dependency 的爆炸式冲突。 
