go mod tidy 为什么删不掉不用的依赖
它只清理 go.mod 中声明但代码里完全没 import 的模块——前提是你的项目里没有隐式依赖。比如 _ 导入、构建标签（// +build）、或测试文件（*_test.go）里引用了某个包，go mod tidy 就会认为它“被用了”。
- 运行前先确认是否在 module 根目录下，否则报错
no go.mod file - 检查有没有
import _ "xxx"，这种导入不会出现在普通代码路径里，但会被go mod tidy认为有效 - 如果用了条件编译（如
// +build windows），确保当前 GOOS/GOARCH 环境和构建目标一致，否则可能漏判依赖 -
go mod tidy -v会输出具体增删行为，比默认静默模式更容易定位“为什么留着这个包”
go mod tidy 和 go get 冲突时怎么办
当你刚 go get xxx@v1.2.3 又立刻 go mod tidy，很可能发现版本回退或替换成间接依赖的旧版——因为 go mod tidy 的目标是满足所有 import 的最小可行版本集，不是保留你手动敲的那条命令。
- 想锁死某个版本？直接改
go.mod里的require xxx v1.2.3行，再跑go mod tidy - 避免
go get自动升级：加-u=patch或干脆不用-u，例如go get example.com/pkg@v2.1.0 - 如果
go mod tidy把你想要的版本降级了，大概率是其他依赖要求更低版本；用go mod graph | grep xxx查谁在拉低版本
CI/CD 里执行 go mod tidy 的正确姿势
很多团队把它当“格式化依赖”的一步塞进 CI，结果构建失败或行为不一致——根本原因是本地 go.sum 和远程 GOPROXY 缓存不一致，或 Go 版本差异导致解析逻辑不同。
- CI 中必须显式指定 Go 版本（如
go1.21），和本地开发环境对齐 - 不要跳过
go mod download直接go mod tidy，尤其在离线或受限网络环境下，前者能提前暴露模块不可达问题 - CI 脚本里建议加校验：执行完
go mod tidy后跑git status --porcelain go.mod go.sum，非空则说明有未提交变更，应失败而非静默覆盖 - 禁止在 CI 中使用
-o或重定向输出到文件，go mod tidy不支持输出到外部路径
go mod tidy 在多模块项目中的陷阱
主模块下有 ./cmd/、./internal/、甚至嵌套 go.mod（比如子 vendor 模块），go mod tidy 默认只作用于当前目录的 go.mod，不会递归处理子模块。
立即学习“go语言免费学习笔记（深入）”；
- 每个含
go.mod的子目录都得单独进目录执行go mod tidy - 如果子模块被主模块
replace过，go mod tidy在子模块里可能拉不到原始版本，需配合go mod edit -dropreplace临时清除 - 跨模块调用时，若子模块未导出接口但主模块 import 了它的内部路径（如
example.com/repo/internal/util），go mod tidy会报错use of internal package not allowed，这不是命令问题，而是模块边界违规
真正麻烦的从来不是命令本身，而是它背后那套依赖图推导逻辑——每次执行前，最好心里清楚当前 import 图覆盖了哪些文件、构建约束有哪些、以及 GOPROXY 是否可信。不然 tidy 来 tidy 去，只是把问题藏得更深一点。
