唯一安全有效的清理命令是go clean -modcache，它幂等地清空$GOMODCACHE中zip包、解压源码及校验文件，不影响go.mod、go.sum或vendor/；手动删除$GOPATH/pkg/mod风险高，易致I/O错误、路径误判或校验失效。
go clean -modcache 是唯一安全有效的清理命令
GoLand 本身不管理 Go 模块缓存，它只是调用 Go CLI 工具链；真正存储下载模块的地方是 $GOMODCACHE（默认为 $GOPATH/pkg/mod），而清理它的标准方式只有 go clean -modcache。这个命令幂等、安全，只删缓存目录里的 zip 包、解压源码和校验文件，完全不影响你的 go.mod、go.sum 或 vendor/ 目录。
常见错误现象包括：cannot find module providing package xxx、checksum mismatch、go list -m all 显示的版本与 go.mod 不一致——这些多数是缓存损坏或 stale 导致，不是 GoLand 的问题。
- 执行前确认
GO111MODULE=on，否则该命令静默无效 - 运行
go env GOMODCACHE确认路径，避免多 GOPATH 或 CI 环境下误判 - 想预估释放空间？先跑
du -sh $(go env GOMODCACHE) - 清理后首次
go build会变慢，但仅限缺失或校验失败的模块，不是全量重拉
别手动删 $GOPATH/pkg/mod，风险远高于收益
有人图快直接 rm -rf $GOPATH/pkg/mod，这看似等效，但容易出问题：
- 多个 GOPATH 或混用
GOBIN时，go env GOMODCACHE和实际路径可能不一致 - IDE 后台（如 GoLand 的 gopls）正读取该目录，强制删除可能引发 I/O 错误或卡死
- CI 环境中
go env GOPATH可能为空，导致删错位置 - 删完没立刻跑
go mod download就构建，会卡在 “downloading” 状态，而非报错提示
真正决定用哪个模块版本的是 go.mod 和 go.sum，缓存路径本身不保存语义。删错目录不会修依赖逻辑，只会拖慢下次构建。
GoLand 配合清理要关掉自动构建
GoLand 默认开启 “Build project automatically”，每次保存都触发 go list 和后台分析，间接往 $GOCACHE 和模块缓存关联路径写东西。这不是必须的，尤其你主要靠终端调试时：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- Settings → Go → Build Tags & Vendoring → 关掉 Build project automatically
- Settings → Tools → File Watchers → 关掉所有与 Go 相关的 watcher
- 检查 Settings → Go → Language Server →
build.ignore是否配置了pkg/或bin/，避免语义分析误触发缓存写入
关掉后，go clean -modcache 效果更干净，也不会被 IDE 后台操作干扰。
清理后要不要立即 go mod download
不需要主动全量下载。Go 工具链会在构建时按需拉取，但以下场景建议补跑：
- 刚切换 Go 版本（比如从 1.24 升到 1.26），部分模块缓存可能跳过校验，
go mod download更稳妥 - CI 构建前想确保环境干净可复现，加
-x参数观察每一步：go mod download -x -
go list -m all输出里有(incompatible)或missing，说明缓存已损坏，此时应配go mod tidy一起用
模块缓存不是“脏数据池”，而是带校验的只读副本；清理只是腾空间，不是解决依赖冲突的手段。最容易被忽略的一点：私有模块必须提前确认 go env GOPRIVATE 已设好，否则清理后 go get 可能因跳过校验而拉错版本。
