go clean -modcache 清理的是模块缓存（$GOMODCACHE，即 $GOPATH/pkg/mod 和 $GOPATH/pkg/sumdb），不影响 $GOPATH/src 下的手动克隆包；仅在 GO111MODULE=on 时生效，用于解决校验失败、版本错乱等问题。
go clean -modcache 清的是什么，不是 GOPATH
现在用 Go 1.11+ 的人基本都启用了 GO111MODULE=on，go clean -modcache 清的是模块缓存（$GOMODCACHE，通常是 $GOPATH/pkg/mod），不是旧式 GOPATH/src 下的手动 clone 包。如果你还在往 $GOPATH/src 里 git clone 项目、手动管理依赖，那 go clean -modcache 对它完全没影响。
常见错误现象：go clean -modcache 执行完，$GOPATH/src 里的旧包还在，误以为命令“没生效”——其实是清错了地方。
-
go clean -modcache只动$GOPATH/pkg/mod和$GOPATH/pkg/sumdb - 要删
$GOPATH/src下的旧包，得手动rm -rf $GOPATH/src/github.com/some/oldrepo - 如果同时混用 module 模式和
$GOPATH/src，Go 工具链会优先走replace或本地src，modcache里的包可能根本没被加载
什么时候该用 go clean -modcache
不是定期“打扫卫生”，而是遇到明确问题时才触发。最典型的场景是：模块校验失败、拉取了错误版本、或升级 Go 后 go build 报奇怪的 checksum mismatch。
常见错误现象：verifying github.com/some/pkg@v1.2.3: checksum mismatch，或者 go list 显示版本和 go.mod 不一致。
立即学习“go语言免费学习笔记（深入）”；
- 执行前先确认
go env GOMODCACHE路径，避免清理了别人共用的缓存（比如 CI 机器） - 清理后首次
go build会重新下载所有依赖，耗时明显变长，别在发布前临时跑 - 如果只是想换一个模块版本，通常
go get some/pkg@v1.4.0就够了，不用清整个 cache
GO111MODULE=off 时 go clean -modcache 会怎样
会静默失败，不报错，也不清理任何东西。
因为 -modcache 是模块模式专属功能，GO111MODULE=off 下 Go 完全不启用模块系统，连 $GOMODCACHE 都不会读取。
- 运行
go clean -modcache后检查$GOPATH/pkg/mod，发现文件全在——不是命令失效，是压根没进逻辑分支 - 此时真正起作用的是
go clean -i -r ./...（清理安装产物和递归依赖对象），但它不碰源码 - 验证方式：执行
go env GO111MODULE，输出off就别指望-modcache了
清理后为什么某些包还是“找不到”
不是缓存没清干净，而是项目本身没声明依赖。Go 模块不会自动把 $GOPATH/src 或历史残留包纳入构建范围。
常见错误现象：import "github.com/old/project" 报 no required module provides package，但目录明明存在。
- 检查
go.mod里有没有对应require行；没有就加go get github.com/old/project@latest - 如果包不在任何公开 registry，又不想发版，可用
replace github.com/old/project => ../local/project -
go clean -modcache不恢复go.mod，也不会重写依赖树——它只管“已知缓存”，不管“该不该有”
真正容易被忽略的点：模块缓存和 go.mod 的一致性是单向的。清缓存不会让 go.mod 回滚，也不会触发自动 go mod tidy。需要人自己判断要不要跟进建议操作。
