go mod tidy 不会删除未被直接引用的间接依赖，仅补全缺失模块并移除彻底无人使用的模块；需结合 go mod graph、go list 等命令人工排查真实依赖。
go mod tidy 不是“清理无用依赖”的万能命令，它只做两件事：补全缺失的模块、删除未被直接引用的模块——但不会删掉间接依赖（即 require 中标记为 // indirect 的项，除非它们彻底没人用了）。
为什么 go mod tidy 没删掉我明明没用的包？
常见误解是认为 go mod tidy 会像 npm prune 那样扫出所有“代码里没 import”的包。实际上它只看 import 语句和 go.sum 的一致性，不分析运行时或测试中是否真用到了某个符号。
- 如果某个包被
test文件 import（比如xxx_test.go），它会被保留在go.mod中 - 如果某个包被另一个已声明的依赖间接引入（哪怕你代码里完全没碰它），且该依赖没升级到剔除它的版本，
go mod tidy不会动它 -
// indirect标记只是说明“你没直接 import”，不代表它可删；只要仍有模块需要它，它就合法存在
如何真正识别并移除未使用的依赖？
得靠组合命令 + 人工验证，go mod tidy 只是其中一环：
- 先运行
go mod graph | grep 'your-unwanted-module'看谁在依赖它 - 用
go list -f '{{.Deps}}' ./... | grep your-module检查是否还有任何包显式声明依赖它 - 临时注释掉疑似无关的
import，再跑go mod tidy—— 如果它从go.mod消失了，说明之前是被那行 import 拉进来的 - 注意：有些包（如
golang.org/x/tools子模块）可能被go命令本身调用（比如go list或 IDE 插件），这类依赖即使代码里没 import，也不建议强删
go mod tidy 的典型误用场景与优化建议
很多人把它当“一键优化”命令反复执行，反而引发问题：
立即学习“go语言免费学习笔记（深入）”；
- 在 CI 中盲目加
go mod tidy && git diff --quiet go.mod || exit 1—— 这会因 Go 工具链升级或 proxy 返回顺序变化导致非预期的go.mod变动，建议锁定GOPROXY和GOVERSION - 在多 module 项目中（如含
./cmd/...和./internal/...），直接在根目录跑go mod tidy可能拉入cmd专用依赖到主go.mod；应按需进入子目录，用go mod init+go mod tidy独立管理 - 想降级某个依赖？别指望
go mod tidy自动回退 —— 它默认取最新兼容版；得先go get example.com/pkg@v1.2.3，再go mod tidy
真正麻烦的是那些被测试、生成代码、或构建 tag 隐藏依赖的模块——它们不会出现在主流程 import 中，但 go mod tidy 仍会保留。这种依赖关系得靠 go list -deps -f '{{.ImportPath}} {{.Indirect}}' ./... 配合 grep 逐层排查，没法全自动。
