go mod tidy 只补全实际 import 的模块并移除未被直接或间接引用的模块，会误删 //go:embed、构建 tag 或测试文件中的依赖，空导入保留，间接依赖需验证后清理。
go mod tidy 会删掉哪些模块
go mod tidy 不是“智能清理”，它只做两件事：补全当前代码实际 import 的模块，移除 go.mod 中存在但项目中没有任何 import 引用、且未被其他已保留模块间接依赖的模块。
常见误判场景：
- 模块仅在
//go:embed或//go:generate中出现 → 不算 import，go mod tidy会删掉 - 模块只用于构建 tag（如
// +build integration）且当前未启用该 tag → 不会被识别为依赖 - 模块被
_空导入（import _ "github.com/x/y"）→ 会被保留，因为空导入仍算显式依赖 - 模块在测试文件（
*_test.go）中 import，但运行go mod tidy时没加-modfile go.sum或未启用 test 模式 → 默认不扫描测试依赖（需加-compat=1.18以上并确保GOOS环境一致）
如何安全地清理间接依赖（require indirect）
间接依赖出现在 go.mod 中带 // indirect 标注的行，它们不是你直接 import 的，而是你依赖的库拉进来的。盲目删除可能破坏构建。
安全操作步骤：
立即学习“go语言免费学习笔记（深入）”；
- 先运行
go mod graph | grep 'your-module'查看谁真正引用了它 - 用
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./...检查当前代码树所有实际依赖路径 - 对疑似冗余的
indirect模块，临时注释掉那行，再执行go build ./...和go test ./...—— 如果失败，说明仍有隐式依赖（比如通过plugin、反射或生成代码） - 某些模块（如
golang.org/x/sys）常被多个标准库包间接引用，即使没显式 import 也不建议手动删
go mod vendor 后还能不能删模块
可以删，但必须在 go mod vendor 之前删。一旦执行过 go mod vendor，vendor/ 目录就变成独立副本，go mod tidy 不会影响它；反之，删完模块后若还保留旧 vendor/，会出现「本地有但 mod 文件没声明」的不一致。
推荐流程：
- 先
go mod tidy - 再
go mod vendor（这会自动同步 vendor 内容到当前go.mod状态） - 检查
vendor/modules.txt是否与go.mod一致 —— 若不一致，说明有残留或 vendor 未更新 - 不要手动删
vendor/下的子目录，否则go build -mod=vendor会报cannot find module providing package
CI/CD 中模块清理容易忽略的点
本地能过，CI 报错，往往是因为环境差异放大了模块引用问题：
- CI 使用的 Go 版本比本地低（如本地 1.22，CI 是 1.20）→ 新版
go mod tidy的依赖解析逻辑更严格，可能拒绝某些模糊的间接依赖 - CI 开启了
GO111MODULE=on但本地是 auto → 导致某些 vendor 或 GOPATH 行为不一致 - CI 运行
go mod tidy前没清理go.sum→ 旧 checksum 可能和新依赖冲突，报checksum mismatch - 多阶段 Docker 构建中，在 builder 阶段 tidy 后没重新
COPY go.mod go.sum .到 final 阶段 → final 镜像里模块状态过期
最稳妥的做法：每次提交前在干净环境中跑一遍 go mod tidy && go mod vendor && go build ./...，而不是只信本地结果。
