详解Golang模块依赖管理中go clean modcache的威力与风险-Golang-PHP中文网

go clean -modcache 只删除 $gomodcache 中的 .zip 包、解压源码目录和校验文件（.info、.ziphash），不删 go.mod、go.sum、vendor/ 或 $gopath/src 项目。

详解golang模块依赖管理中go clean modcache的威力与风险

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。

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，这点比日志更可信。