报 zip: not a valid zip file 是缓存损坏所致，需定位并删除对应模块缓存目录（如 $gomodcache/github.com/some/pkg@v1.2.3），再执行 go mod download 重建；若 verifying 卡住，则因 sum.golang.org 不可达，可临时设 gosumdb=off 调试。
go mod download 报 zip: not a valid zip file 怎么办
这是缓存文件损坏的明确信号，不是网络重试就能解决的。Go 从代理下载模块后会解压校验，若中途断连或代理返回不完整响应，缓存里就剩个残缺 zip —— 后续所有命令都会复用它，反复报错。
- 直接定位并删除对应模块缓存：报错里有类似
github.com/some/pkg@v1.2.3的路径，就去$GOMODCACHE/github.com/some/pkg@v1.2.3目录下删掉整个文件夹 - 别只删 zip 文件：缓存目录里还有
.ziphash、go.mod等校验文件，全删才干净 - 删完立刻执行
go mod download，Go 会重新拉取完整包，不是从头缓存所有依赖
GOPROXY=direct 为什么还卡在 verifying 阶段
因为 verifying 是 checksum 校验环节，和代理无关，而是访问 sum.golang.org。国内网络环境下这个域名基本不可达，Go 会反复重试直到超时，看起来像卡住。
- 临时关闭校验（仅调试）：
GOSUMDB=off go mod download - 更稳妥的做法是换 sumdb 源：
go env -w GOSUMDB=sum.golang.org+replace=gosum.io+ca=trusted（需确认 gosum.io 可达） - 切勿长期设
GOSUMDB=off：提交代码前必须恢复，否则 CI 构建会失败
go clean -modcache 后依赖还是不对
清缓存只是清本地副本，不解决远程源本身的问题。如果模块作者已撤回 tag、改写历史或私有库权限变更，重下也无效。
- 先确认模块真实状态：
curl -I https://goproxy.cn/github.com/xxx/yyy/@v/v1.2.3.info看是否返回 200 - 检查
go.mod中版本号是否拼错，比如v1.2.3写成v1.2.3a - 私有模块要确保
GOPRIVATE已覆盖该路径，且git clone命令能手动成功
IDE 里 go mod tidy 不生效，终端却可以
IDE（如 VS Code、GoLand）通常不继承 shell 的环境变量，尤其 GOPROXY 这种关键变量，容易被 IDE 自带的 Go 设置覆盖。
- 在 IDE 终端里单独运行一遍
go env -w GOPROXY=https://goproxy.cn,direct - VS Code 用户检查
settings.json是否设置了"go.toolsEnvVars"，里面可能硬编码了错误的GOPROXY - GoLand 用户进
Settings > Go > GOPATH页面，确认 “Go tools environment” 里GOPROXY值正确
