go clean -modcache会彻底删除$gopath/pkg/mod（或$gomodcache）下所有模块的解压源码目录（如github.com/user/repo@v1.2.3/）及cache/download中的.zip、.info、.ziphash文件，但不触碰go.mod和go.sum。
go clean -modcache 会删掉哪些临时解压目录
它会彻底删除 $GOPATH/pkg/mod（或 $GOMODCACHE）下所有模块的解压源码目录，包括：github.com/user/repo@v1.2.3/ 这类路径下的完整文件树；同时清除 cache/download 子目录里对应的 .zip、.info 和 .ziphash 文件。这些就是 Go 下载模块后解压出来的“临时”源码副本——它们不是构建产物，但占空间、可能损坏、且不会被 go mod tidy 触及。
为什么 go mod tidy 不清理这些目录
go mod tidy 只操作 go.mod 和 go.sum，它不碰磁盘上的已下载模块文件。即使你从 go.mod 中删掉了某个 require，对应模块的解压目录仍留在 pkg/mod 里，除非手动清理或等 go clean -modcache 执行。
- 常见误判：看到
go mod graph里没有某模块，就以为它的源码目录已被删——其实只是没被引用，目录还在 - 真正触发清理的只有两个动作：
go clean -modcache（全删），或手动rm -rf $GOMODCACHE/github.com/xxx（慎用，易漏依赖） - CI 流水线里加
go clean -modcache后首次构建变慢，是因为所有模块都要重下+重解压，不是缓存没生效
清理前要不要备份，备份什么
不需要备份 pkg/mod 整个目录，但必须保留两样东西：
- 当前项目的
go.mod和go.sum——它们是重建依赖的唯一权威来源 - 运行
go list -m -json all > deps.json，生成带Replace和Indirect标记的结构化快照，比go mod graph更准，尤其对私有模块和 replace 场景
如果用了 GOPROXY=off 或私有代理，确认 go env GOPRIVATE 已设好，否则清理后 go get 可能因跳过校验而拉错 commit。
有没有更轻量的清理方式，避免全量重下
有，但需配合分析工具，适合磁盘紧张但不想拖慢 CI 的场景：
- 用
go mod graph | awk '{print $1}' | sort -u提取当前项目实际依赖的所有模块路径（含间接依赖） - 对比
ls $GOMODCACHE/cache/download下的域名级缓存目录（如git.internal.company.com），只删那些不在依赖列表里的私有域名子目录 - 对公共模块（如
golang.org/x/...），优先跑go mod tidy -v再执行go clean -modcache，因为tidy会先收缩go.mod范围，后续-modcache删除的体积自然变小
真正容易被忽略的是：模块缓存里混着不同代理源的同版本模块（比如之前用过 proxy.golang.org，后来切到 Nexus），这种混合状态不会报错，但 checksum 验证可能失效——go clean -modcache 是唯一能彻底归一化的手段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
