报 zip: not a valid zip file 错误是本地缓存损坏所致，应定位并删除对应模块的 .zip 及 .ziphash 文件；checksum mismatch 多因 gosumdb 不可达，可临时关闭校验验证，但不可长期禁用。
第三方依赖包损坏不是网络问题，而是本地缓存污染或校验失败导致的“假失败”——直接删对应缓存条目比重装Go快得多。
go mod download 报 zip: not a valid zip file 怎么办
这不是网络超时，是本地缓存里某个模块的 .zip 文件已损坏。Go 下载时会解压它，但损坏的压缩包无法解压，就卡在这里。
- 先看报错里含哪个路径，比如
github.com/some/pkg@v1.2.3 - 进
$GOPATH/pkg/mod/cache/download/（或$GOMODCACHE），按域名和路径逐级找，定位到some/pkg/@v/v1.2.3.zip - 删掉这个
.zip和同名的.ziphash文件即可 - 再跑
go mod download，Go 会重新下载该版本
checksum mismatch 错误本质是 GOSUMDB 不可达
go.sum 校验失败，90% 情况下不是包被篡改，而是 sum.golang.org 访问失败，导致 Go 拒绝使用缓存里的模块。
- 临时验证：执行
go env -w GOSUMDB=off，再试go mod download—— 若成功，说明就是校验服务问题 - 别长期关
GOSUMDB，开发调试可用，CI 或发布前务必恢复 - 更稳妥的做法是配代理兜底：如
go env -w GOPROXY="https://goproxy.cn,direct"，direct保证私有模块或校验服务不可达时能 fallback
go clean -modcache 不等于“重装依赖”，要慎用
go clean -modcache 会清空整个模块缓存，包括所有已下载的 .zip、解压后的源码和 go.sum 条目。后续首次 go mod download 会慢很多，且可能触发重复下载。
- 只在以下情况用：
go mod tidy完全无响应、多个模块同时报校验错、或你刚改过go.mod但缓存仍残留旧路径 - 清完后必须立刻跑
go mod tidy，否则go build会因缺失依赖失败 - 注意：该命令不影响
$GOPATH/pkg（那是编译缓存），只清模块下载缓存
真正麻烦的不是损坏本身，而是错误日志里不显式告诉你哪个包坏了——得靠报错路径反查缓存位置，再手动删。遇到连续几个包都 zip invalid，大概率是代理中途断连写了一半的文件，这时候清整个 download/ 子目录比单删更快。
