go mod download 拉到损坏 zip 包主因是缓存机制不校验 zip 完整性，仅依赖 sum.db 哈希，导致网络中断、代理截断、磁盘写入失败或 CDN 污染产生的损坏 zip 被静默保留，直至解压时才报“invalid archive: zip: not a valid zip file”。
为什么 go mod download 会拉到损坏的 zip 包？
Go 模块缓存（$GOPATH/pkg/mod/cache/download）里的 zip 文件可能因网络中断、代理截断、磁盘写入失败或 CDN 缓存污染而损坏，表现为解压失败、校验和不匹配或 go build 报错 invalid module zip。
这类损坏通常不会触发自动重试——Go 默认只校验 sum.db 中的哈希，而 zip 文件本身未被实时校验，直到真正解压时才暴露问题。
- 常见错误现象：
go: extracting github.com/some/pkg@v1.2.3: invalid archive: zip: not a valid zip file - 不是所有
go mod tidy都能修复——它只更新依赖图，不校验已有缓存 - 损坏包可能卡在
download目录下，但replace或proxy设置无法绕过它
手动清理损坏模块缓存的可靠路径
不要直接删整个 pkg/mod——太重，且会丢失已验证的 checksum 和本地 replace 映射。精准定位并清理损坏项更安全。
- 先查出具体模块和版本：
go list -m -f '{{.Path}} {{.Version}}' github.com/some/pkg - 定位缓存路径：
$GOPATH/pkg/mod/cache/download/github.com/some/pkg/@v/v1.2.3.zip（注意路径中斜杠转为/，版本前带@v） - 删掉该 zip 及其同名
.zip.hash文件（否则下次仍会跳过校验） - 再运行
go mod download github.com/some/pkg@v1.2.3触发重拉
如果不确定哪个 zip 坏了，可临时启用调试：GODEBUG=modcacheverify=1 go build，它会在解压前强制校验所有缓存 zip。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
用 go clean -modcache 的真实适用场景
go clean -modcache 是全量清理，适合以下情况：
- 你刚切换了 GOPROXY（比如从私有 proxy 切回
https://proxy.golang.org），旧缓存里混了不兼容签名的包 - 升级 Go 版本后首次构建，发现大量
checksum mismatch——新版本对 sum.db 校验更严格 - 怀疑本地磁盘有静默错误（如 ext4 journal corruption），单个清理不可靠
注意：go clean -modcache 不清空 $GOPATH/pkg/mod 下的 unpacked 模块（即 github.com/xxx@v1.2.3 目录），只清 cache/download 和 cache/download/sumdb。所以重建速度比从零 go mod download 快得多。
预防下次再拉坏：设置超时与校验开关
默认的 go 命令不设 HTTP 超时，小概率遇到代理挂起连接导致 zip 截断。可在环境变量中加固：
-
export GOPROXY=https://proxy.golang.org,direct（避免 fallback 到不稳定的 direct 源） -
export GOSUMDB=sum.golang.org（确保 checksum 来源可信，禁用off） - 加一层 curl 验证（CI 场景推荐）：
curl -fL -o /dev/null https://proxy.golang.org/github.com/some/pkg/@v/v1.2.3.zip，失败则提前报错
真正容易被忽略的是：即使设置了 GOPROXY，Go 仍可能 fallback 到 direct 拉取私有模块——这时 zip 损坏风险最高，务必确认私有仓库返回的是完整、无 chunked transfer-encoding 截断的响应。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
