go clean -modcache会彻底删除$gomodcache目录下所有自动下载的模块zip包及解压后的源码，包括cache/download/中的原始包和github.com/xxx/yyy@v1.2.3等解压目录，清空后重建需重新下载、校验、解压。
go clean -modcache 会删掉什么
它会清空整个 $GOMODCACHE 目录，也就是所有通过 go get 或 go build 自动下载并解压的模块源码和 zip 包。默认路径是 $GOPATH/pkg/mod（比如 $HOME/go/pkg/mod），里面既有 cache/download/ 下的原始 zip，也有 github.com/xxx/yyy@v1.2.3 这样的解压后源码目录。
这不是“清理部分缓存”，而是**彻底删除**——删完之后再构建，所有依赖都会重新下载、校验、解压。所以它只适合明确需要重置依赖状态的场景，比如：
- 怀疑某个模块 zip 文件损坏（
go mod verify失败但没报错） - 刚切换了私有代理（如从
https://goproxy.cn换成自建GOPROXY），旧缓存里混着不同来源的同版本模块 - CI 流水线中避免跨 job 缓存污染（注意：首次构建会变慢）
为什么 go clean -modcache 有时像没起作用
常见错觉来源有两个：
-
go clean -modcache不影响vendor/目录 —— 如果项目启用了go mod vendor，那vendor/里的代码是独立副本，删缓存不会动它 - 某些 IDE（如 VS Code + gopls）会自己缓存模块元数据，删完
$GOMODCACHE后，gopls 可能仍从本地索引里读旧信息，需重启编辑器或执行gopls restart - 如果项目根目录下有
go.work，且 workspace 内多个模块共用同一份依赖，go clean -modcache仍只清全局缓存，不会自动同步清理 workspace 级别临时状态
想清理得更干净，还得配合哪些操作
单靠 go clean -modcache 并不能覆盖所有临时产物。真正“彻底”需要组合以下几步：
- 运行
go clean -modcache—— 清模块源码和 zip - 手动删
$GOCACHE（或运行go clean -cache）—— 清编译中间产物（.a文件），尤其当你切换过CGO_ENABLED、GOOS或 Go 版本时必须做 - 删项目级
vendor/（如有）——rm -rf vendor/，再go mod vendor重建 - 检查并清理
go.work中引用的本地模块路径，避免残留 symlink 或 stale checkout
注意：go clean -i 在这里基本无效——它只删当前目录 main 包安装的二进制，跟模块缓存无关。
CI 环境里要不要每次都跑 go clean -modcache
要，但得看上下文。如果每次构建都用全新容器或干净 workspace，加 go clean -modcache 是稳妥做法，能杜绝跨构建的模块污染；但如果 CI 配了模块缓存（比如 GitHub Actions 的 actions/cache 缓存 $GOMODCACHE），那就**不能加**——否则缓存失效，每次都是冷启动，反而拖慢构建。
真正容易被忽略的是：很多人在本地调试时反复 replace 本地路径，改完又忘了删 replace 行，结果 go clean -modcache 根本不解决这个问题——它清的是下载内容，不是 go.mod 里的声明逻辑。
