go mod tidy是Go官方唯一认可的依赖清理方式，它基于全部.go文件import语句重新计算依赖图，同步增删go.mod和更新go.sum；手动删require行易致校验和错误、间接依赖断裂及构建失败。
go mod tidy 是唯一可靠的方式
直接手动删 go.mod 里的 require 行几乎一定会出问题：残留的校验和、间接依赖断裂、go.sum 不一致，甚至构建失败。Go 官方只认可 go mod tidy 作为清理入口——它不是“删掉某一行”，而是基于整个项目所有 .go 文件的 import 语句重新计算依赖图，再同步增删 go.mod 和更新 go.sum。
执行前必须确保：
- 所有
.go文件（包括_test.go、main.go、生成代码如mock_*.go）已保存且无语法错误 - 刚删掉的
import语句已真正提交或至少保存，否则tidy看不到变更 - 没有运行时动态加载（如
plugin.Open或reflect.ImportPath），这类依赖tidy永远识别不了
空白导入和条件编译会让包“删不掉”
如果你删了 import "github.com/foo/bar"，但还留着 import _ "github.com/foo/bar"（空白导入），go mod tidy 会认为这个包被显式需要，绝不会删。同理，如果包仅通过 //go:build windows 或 //go:embed 间接使用，而主干代码没 import，tidy 默认也不会处理它——除非你加 -compat=1.21 参数启用更严格的构建约束解析。
常见误判场景：
-
import _ "net/http/pprof"这类调试用包，即使业务代码不用，只要存在就保留 -
//go:build ignore或// +build ignore标记的文件，tidy会跳过分析，其中的 import 不参与依赖计算 - 测试文件里用了某个包，但你只跑
go build ./没跑go test ./，tidy可能误判为“未使用”
删完后要验证是否真干净
go mod tidy 输出里出现 removing unused requirement 只是表面信号，不代表彻底清理完成。真正要确认，得看三件事：
- 运行
go list -m all | wc -l，对比 tidy 前后数字下降才说明依赖数减少 - 执行
go mod graph | grep 'your-unwanted-package'，确保返回空——说明它既没被直接 import，也没作为传递依赖残留 - 手动打开
go.mod，检查目标包是否真的不在require列表里，且没被replace或exclude隐式保留
特别注意：如果该包曾被其他依赖旧版本引用过，tidy 可能因版本兼容性策略暂时保留它，这时需配合 go mod graph 查清依赖链源头。
本地磁盘上的包文件不会自动消失
go mod tidy 只改 go.mod 和 go.sum，完全不影响 $GOPATH/pkg/mod 目录里的缓存文件。那些被删掉的包依然躺在磁盘上，越积越多。
释放空间有两个选择：
- 全局清理：
go clean -modcache—— 会清空整个模块缓存，适合 CI 或换机器后用，但会影响其他项目首次构建速度 - 精准清理：手动进
$GOPATH/pkg/mod，删对应目录，比如github.com/some/oldpkg@v0.1.0，前提是确认没有其他项目还在用它
别用 go clean -i，它删的是安装后的二进制（$GOBIN），对模块缓存无效；也别碰 $GOPATH/src，那是老 GOPATH 模式遗留，Go Modules 下它基本不参与依赖解析。
