17370845950

用 go mod tidy 清理未使用依赖，它只移除既无直接 import 也无间接依赖的包；手动删 require 行易破坏构建，且会被自动恢复。

直接答案：用 go mod tidy，不是手动删 go.mod

它不是“删包命令”，而是**依赖关系同步器**——只在模块既没被任何 .go 文件 import，也没被其他已保留模块间接依赖时，才从 go.mod 和 go.sum 中移除。手动删 require 行极可能破坏构建，且下次 go build 会自动加回来。

go mod tidy 为什么有时不删你认为“没用”的包

常见误判场景，它其实很谨慎：

• 包被 _ "github.com/some/pkg" 方式导入（仅触发 init()）→ tidy 会保留
• 包出现在 //go:embed 或 //go:generate 注释里，但没显式 import → 静态分析不可见，可能被误删
• 代码里用了构建标签（如 // +build windows），而当前环境未启用 → tidy 不扫描该分支的 import，可能删掉本该留下的包
• 某个包被测试文件 import（xxx_test.go），但主逻辑没用 → 它仍会被保留，因为 tidy 默认分析整个 module（含测试）
• go.mod 中有 replace 或 exclude → 可能干扰依赖图计算，建议临时注释后重试

安全清理的实操流程

别信“运行一次就完事”，关键在验证和边界控制：

• 先 git status 确认没未提交变更，或 git stash 备份当前状态
• 运行 go mod tidy -v，看输出里有没有类似 removing unused module github.com/stretchr/testify v1.8.0 的提示
• 立刻执行 go build ./ 和 go test ./，尤其注意是否报 undefined: xxx 或 cannot find package
• 检查 git diff go.mod，确认被删的包确实不再需要；若发现误删，git checkout -- go.mod 回退即可
• 如果项目用了 vendor，tidy 不会动它——需额外跑 go mod vendor 同步

清理后还要注意的残留问题

go mod tidy 只改 go.mod 和 go.sum，不碰磁盘缓存和本地源码：

• 旧版本模块仍留在 $GOPATH/pkg/mod 里 → 想彻底清理，运行 go clean -modcache（会清空全部缓存，首次构建变慢）
• 曾经手动 go get 过的包，其源码可能还躺在 $GOPATH/src/ 下 → tidy 不管它，但也不会再用，可手动 rm -rf 对应路径
• 某些工具依赖（如 golang.org/x/tools）虽未在业务代码中 import，但 CI 脚本或编辑器插件需要 → 别只看代码，得看整个工程链路

最常被忽略的一点：跨平台项目里，不同 GOOS/GOARCH 下的依赖可能不同。你在 Linux 上跑 tidy，不代表 Windows 构建一定没问题——CI 中必须用目标平台环境执行一遍 go mod tidy -v &&