go clean -modcache 删除的是 $GOMODCACHE（默认 $GOPATH/pkg/mod）下所有已下载的模块源码、.zip 包及校验文件，但不删除 go.mod、go.sum 和 vendor/；删完报“cannot find module”是因为 Go 懒加载，需先解析 go.mod 再按需下载，且可能因 GO111MODULE=off、缺失 go.mod 或 replace 路径无 go.mod 导致失败。
go clean -modcache 删的是什么，为什么删完还报“cannot find module”
它删的是 $GOMODCACHE（默认为 $GOPATH/pkg/mod）下所有已下载的模块源码、.zip 包和校验文件（包括 cache/download/ 下的 .info、.ziphash），但不碰 go.mod、go.sum 和 vendor/。删完立刻执行 go build 报 “cannot find module providing package xxx”，不是命令失败，而是 Go 还没来得及重下——它需要先解析 go.mod，再按需拉取，这个过程是懒加载的。
常见误操作：
- 没确认
GO111MODULE=on，导致go clean -modcache静默跳过 - 删完马上跑
go run main.go，但当前目录没go.mod，Go 退化到 GOPATH 模式，自然找不到模块 - 项目用了
replace指向本地路径，而该路径下没有go.mod，清理后无法 fallback 构建
什么时候必须用 go clean -modcache，而不是 go mod tidy
go mod tidy 只改 go.mod 和 go.sum 的内容，它不删磁盘上的任何模块文件；go clean -modcache 才真正释放空间、解决缓存污染。以下情况绕不开后者：
-
go list -m all显示的版本和go.mod里写的不一致（比如显示v1.2.3，但go.mod是v1.2.4） - 切换 Git 分支后
go build报checksum mismatch，且go.sum没改过 -
du -sh $(go env GOPATH)/pkg/mod超过 10GB，但项目实际只依赖不到 50 个模块 - 启用了私有代理（如 Nexus），但
GOSUMDB=sum.golang.org，本地缓存校验数据和代理返回不匹配
只想删某个模块，别全清
全量 go clean -modcache 在团队协作中容易引发重复下载风暴。更精准的做法是手动删指定模块：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 删解压后的源码：
rm -rf $(go env GOMODCACHE)/github.com/xxx@v1.2.3 - 删原始 zip 和校验数据：
rm -rf $(go env GOMODCACHE)/cache/download/github.com/xxx - 删完建议立刻跑
go mod verify，确保后续下载的模块哈希与go.sum对得上 - 如果模块域名是私有的（如
git.internal.company.com），记得提前确认go env GOPRIVATE已设好，否则重下时可能被代理劫持
清理后磁盘空间没变小？可能是句柄没释放
Linux/macOS 下，go clean -modcache 删除的是文件链接，但若 VS Code、GoLand 或后台 go build 进程还在读这些文件，空间不会立刻归还。这不是命令失效，是系统行为。
验证是否真清了：
- 先关掉 IDE 和构建工具
- 执行
go clean -modcache - 运行
lsof +D $(go env GOMODCACHE) | wc -l，输出为0才说明没进程在占用 - 想立刻见效，可补一句
go build -a ./强制重编译，旧缓存文件句柄会被自动释放
真正难处理的不是“怎么删”，而是删完之后谁在用、从哪拉、校验对不对——这些细节一旦漏掉，问题会以更隐蔽的方式回来。
