go list -m all 列出所有直接和间接依赖模块及其版本，反映完整模块图结构；go mod graph 定位冗余包引入路径；go mod why 验证包是否被实际 import；清理后需 go mod tidy -v 并验证构建、测试及 vendor。
用 go list -m all 查出所有直接和间接依赖
这是最基础也最关键的一步。很多开发者只看 go.mod 里的显式 require，但真正占用空间、引入潜在风险的是整个依赖树。执行：
go list -m all会输出当前模块下所有已解析的模块（含版本），每行格式为
module/path v1.2.3。注意：这个命令不检查是否被实际 import，只反映模块图结构。用 go mod graph 定位冗余包的引入路径
当发现某个包（比如 github.com/sirupsen/logrus）出现多个版本，或存在明显冷门/废弃库时，得知道谁在拉它。运行：
go mod graph | grep logrus能列出所有引用它的模块路径。常见现象是：A → B → C → logrus v1.9.0，同时 A → D → logrus v1.12.0 —— 这说明 B 和 D 各自锁了不同版本，而你可能根本没在代码里 import C 或 D。
更实用的写法是：
go mod graph | awk '{print $2}' | sort | uniq -c | sort -nr | head -10快速找出被引用次数最多的模块，这些往往是“依赖黑洞”。用 go mod why 验证某个包是否真被使用
别光看 graph 就删，先确认它是否被任何源文件 import。例如怀疑 golang.org/x/net 是冗余的：
go mod why golang.org/x/net如果输出
# golang.org/x/net 后跟着 (main module does not need it)，那基本可判定为未使用；但如果显示 # github.com/xxx/yyy<br>import github.com/xxx/zzz<br>import golang.org/x/net/http2，说明有间接 import 路径，删前得查清 zzz 是否真用到了 http2。
容易踩的坑：
• go mod why 只检查 import 路径，不检查 build tag 或 test-only 依赖
• 某些包（如 unsafe 或标准库子包）不会出现在 why 结果里，但它们不是冗余问题
• 如果项目用了 //go:embed 或 cgo，why 无法覆盖这些隐式依赖
清理后必须跑 go mod tidy 并验证构建与测试
删掉 replace 或手动编辑 go.mod 后，不能只靠 go mod download。必须执行：
go mod tidy -v加
-v 才能看到哪些模块被添加/删除。它会重算最小版本选择，并自动移除未使用的 require。关键验证点：
• go build ./... 是否通过（尤其检查 CGO_ENABLED=0 场景）
• go test ./... 是否全绿，某些测试可能依赖旧版行为
• 检查 vendor 目录（如果启用）是否同步更新，避免 CI 构建失败
• 注意 go.sum 文件变化，不同版本 checksum 不同，不要手动删行
真正麻烦的从来不是怎么删，而是某个下游模块把一个老旧的、带安全漏洞的 crypto 工具包作为 transitive dependency 锁死了，而你又不能升级那个下游模块——这种时候，replace 是唯一出路，但得清楚知道你在绕过什么。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
