go list -m all是最可靠、无需额外工具的依赖快照方式，但它仅输出扁平化列表，不体现层级；要查“谁引入了谁”，必须配合go mod graph（输出原始依赖边）和go mod why -m（追溯最短引入路径）协同使用。
go list -m all 是最可靠、无需额外工具的依赖快照方式，但它只给扁平列表，不体现层级；真要查“谁引入了谁”，得靠 go mod graph 和 go mod why 配合使用。
用 go list -m all 看全量依赖但别误读层级
它输出的是当前模块及其所有间接依赖的路径和版本，一行一个，例如：
myproject v0.0.0-00010101000000-000000000000 github.com/gin-gonic/gin v1.9.1 golang.org/x/net v0.23.0
常见误区：
- 运行
go list -m（不带all）只会输出当前模块名，不是依赖列表 - 在非
go.mod所在目录执行会报no modules found - 输出里带
// indirect标记的模块，说明它没被你直接require，而是被其他依赖拉进来的 -
go list -m all不受// +build ignore影响，它只看go.mod声明，不解析实际 import
用 go mod graph 查“谁依赖谁”的原始边关系
go mod graph 每行输出形如 A B@v1.2.3，表示模块 A 直接 import 了 B 的这个版本。它是构建依赖树的原始数据源。
实用技巧：
- 查某个模块是否被多版本共存：
go mod graph | grep 'golang.org/x/text'，如果出现两行以上不同版本，就得警惕冲突 - 过滤出主模块的直接依赖：
go mod graph | grep "^$(go list -m) " | cut -d' ' -f2 - 注意：replace 的本地路径（如
./local-fix）在输出里仍显示为原始模块路径，实际编译用的是替换后的内容 - 该命令不包含
indirect模块——它们虽在go.mod里，但未被任何模块显式依赖
用 go mod why -m 追查单个模块的引入链路
当你在 go list -m all 里看到一个陌生模块（比如 gopkg.in/yaml.v2），又不确定是谁带进来的，go mod why -m gopkg.in/yaml.v2 就是唯一能给出明确路径的答案。
它的输出类似：
# gopkg.in/yaml.v2 myproject github.com/spf13/cobra github.com/spf13/pflag gopkg.in/yaml.v2
关键点：
- 它只返回一条最短路径，不是全部可能路径
- 路径中每个环节都真实存在 import 关系（即编译期可验证）
- 对
replace或exclude模块同样有效，但不会告诉你替换目标是谁——得自己查go.mod - 如果模块根本没被任何包 import，
go mod why会报unknown import path，这时它大概率是冗余项
容易被忽略的边界情况
依赖分析不是静态快照。以下情况会让 go list -m all 和实际构建行为不一致：
- 跨平台构建（
GOOS=js或GOARCH=wasm）时，.Deps列表可能完全不同 -
go test会额外加载_test后缀包和测试专用依赖，需加-test参数才可见 - CI 环境刚拉代码没跑
go mod download，go list -m all仍能列出模块，但.Version可能为空或为伪版本 - 真正确认二进制里嵌了哪些模块，得看
go version -m your-binary，那是 build 时刻的真实快照
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
