go mod tidy 只删除未被任何 .go 文件直接或间接 import 的模块，保留间接依赖、replace/exclude 中的包、test 文件引用、//go:embed 或 //go:generate 引用的包；不升级降级版本，与 go get -u 混用易致 go.mod 震荡；vendor 模式下仍有效但不自动清理 vendor 目录；go111module=off 下静默失败；安全清理需分步验证而非一键操作。
go mod tidy 为什么删不掉某些依赖
它只清理 go.mod 中没有被任何 .go 文件直接或间接 import 的模块，但不会动那些被间接引用、或仅在 replace/exclude 里出现的包。比如你用 github.com/some/lib，它内部依赖 golang.org/x/net，即使你代码里没写 import "golang.org/x/net"，go mod tidy 也会保留后者——这是正确行为，不是 bug。
常见误判场景：
- 你删了 import，但
go.mod里还留着require行 →go mod tidy不会主动删，得先go mod edit -droprequire=xxx或手动删再 tidy - 有
//go:embed或//go:generate引用的包，可能不触发 import 检测 → 实际仍被需要，tidy 不会动 - 测试文件（
*_test.go）里 import 的包，哪怕只在 test 中用，也会被保留在go.mod中
go mod tidy 和 go get -u 冲突怎么办
go get -u 会升级依赖到最新兼容版本，并可能把新版本写进 go.mod；而 go mod tidy 只做“最小必要收敛”，不升级、不降级。两者混用容易导致 go.mod 反复震荡。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 想升级：用
go get -u或更精确的go get example.com/pkg@latest，之后立刻跑一次go mod tidy收尾 - 想锁死版本：别用
-u，改用go get example.com/pkg@v1.2.3，再 tidy - CI/CD 中应禁用
go get -u，只允许显式指定版本 +go mod tidy，避免非预期变更
go mod tidy 在 vendor 模式下是否还有效
有效，但行为有差异：它仍会更新 go.mod 和 go.sum，也会同步更新 vendor/ 目录内容，但不会自动删除 vendor/ 中多余目录——那是 go mod vendor 的职责。
容易踩的坑：
- 执行
go mod tidy后没跟go mod vendor→vendor/里的包版本可能滞后于go.mod - 手动删过
vendor/子目录 →go mod tidy不会恢复，必须go mod vendor全量重刷 -
GO111MODULE=off下运行go mod tidy会静默失败，无提示，务必确认模块模式开启
如何安全地批量清理未使用依赖
go mod tidy 本身不提供“dry-run”或“只报告不修改”模式，但可以配合工具辅助判断。真正能落地的清理流程是分步验证，而非一键清空。
推荐做法：
- 先用
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./... | sort -u > deps.txt导出所有实际加载的包 - 对比
go mod graph | cut -d' ' -f1 | sort -u得到所有出现在go.mod中的模块名 - 取差集，找出只在
go.mod里存在、却不在 import 图中的模块 → 这些才是可安全 drop 的候选 - 对每个候选执行
go mod edit -droprequire=xxx，再go build ./...验证是否真不影响构建
注意：go mod tidy 不处理条件编译（如 // +build ignore）下的 import，这类依赖是否冗余，得人工核对构建标签上下文。
