go clean -modcache 只删除 $GOMODCACHE 中的 .zip 包、解压源码目录和校验文件（.info、.ziphash），不删 go.mod、go.sum、vendor/ 或 $GOPATH/src 项目。
go clean -modcache 到底删什么，不删什么
它只动 $GOMODCACHE（默认是 $GOPATH/pkg/mod）里的三类东西：.zip 包、解压后的源码目录（如 github.com/foo/bar@v1.2.3/）、校验文件（.info、.ziphash）。不会碰你项目里的 go.mod、go.sum，也不会删 vendor/ 或 $GOPATH/src 下的手动 clone 项目。
常见误判是以为删完就 build 不了——其实只是首次构建会慢，因为 go build 或 go mod download 会按需重拉，路径和版本全由 go.mod 决定。
哪些情况非清不可，哪些纯属白忙活
必须清的信号很明确：
-
go list -m all显示的版本和go.mod里写的对不上，尤其在切分支或回退go.mod后 - 报
invalid version: unknown revision，但远程 tag 确实存在 - 启用了私有 GOPROXY 后频繁
checksum mismatch，且go env GOSUMDB没关 -
du -sh $(go env GOPATH)/pkg/mod超过 10GB，而项目实际依赖不到 50 个模块
别清的情况：只是改了自己代码、升级了 Go 版本、或者想“让构建更快”——这些跟模块缓存无关，该清的是 go clean -cache。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
执行前必须确认的三件事
这条命令静默失败的概率比你想的高：
- 确保
GO111MODULE=on，否则go clean -modcache什么也不做 - 确认
go env GOPATH和go env GOMODCACHE路径一致，有些环境设了GOMODCACHE到别处 - 如果用私有模块，检查
go env GOPRIVATE是否已设置，否则清理后go get可能跳过校验拉错版本
执行后建议立刻跑 go mod verify，验证新拉的模块和 go.sum 是否匹配——不是所有代理都严格返回一致的 zip。
替代方案：不全清，只动脏的
团队协作中全量清理等于让所有人重新下载，带宽和时间成本高。更精准的做法：
- 用
go mod graph | awk '{print $1}' | sort -u > used.txt提取当前项目实际用到的所有模块名 - 对比
ls $(go env GOMODCACHE)/cache/download下的域名目录，手动删掉已下线的私有仓库缓存（比如git.internal.company.com/old-service） - 对公共模块，先
go mod tidy -v清掉go.mod里冗余的require，再清缓存，范围自然缩小
真正容易被忽略的是：清理后 go build -v 输出里每行开头的 Fetching 才是真实拉取地址——它暴露了你配置的 GOPROXY 是否生效、是否 fallback 到了 public proxy，这点比日志更可信。
