go mod download卡住或报403主因是goproxy未配fallback且direct未置末尾，或goprivate缺失导致私有模块被转发至公共代理；需同时配置goproxy=https://goproxy.cn,direct和goprivate=git.internal.company.com,github.com/my-team/*，并确保go111module=on、vendor目录已清理、ci环境显式注入变量。
go mod download 卡住或报 403，先确认 GOPROXY 和 GOPRIVATE 是否配对
企业私有云里最常踩的坑是：只设了 GOPROXY，却忘了加 GOPRIVATE。结果所有模块（包括 git.internal.company.com）全被转发到公共代理，必然 403 或 “module lookup failed”。这不是权限问题，是路由错位。
必须同时配置：
-
go env -w GOPROXY=https://goproxy.cn,direct（国内稳定，支持 fallback） -
go env -w GOPRIVATE=git.internal.company.com,github.com/my-team/*（多个域名用英文逗号分隔，不能有空格） - 若用 SSH 克隆，运行
ssh -T git@git.internal.company.com确认连通；若用 HTTPS，提前配好 Git 凭据或设GIT_TERMINAL_PROMPT=0
go clean -modcache 后仍拉不到私有模块？检查 vendor 目录和 GO111MODULE
私有云环境常因历史遗留问题保留 vendor 目录，导致 go build 绕过模块系统、跳过 GOPROXY 和 GOPRIVATE——你改了配置也白搭。
验证方式：
- 运行
go env GO111MODULE，输出必须是on（不是auto） - 删掉项目根目录下的
vendor文件夹（除非 CI 明确要求 vendor） - 执行
go mod download -v，观察日志里私有模块是否走的是直连 URL（如https://git.internal.company.com/xxx），而不是代理地址
CI/CD 流水线里 GOPROXY 不生效？环境变量未继承或被覆盖
流水线容器（如 Jenkins Agent、GitLab Runner）默认不读取你的 shell 配置，go env -w 在本地终端生效，但在 CI 脚本里无效。
正确做法是显式注入：
- 在流水线脚本开头加：
export GOPROXY=https://goproxy.cn,direct和export GOPRIVATE=git.internal.company.com - 避免使用
go env -w，它写入的是用户级配置，在无 home 目录的容器中可能失效 - 若用 GitHub Actions，需在
env:下声明，而非靠run:里的 export（后者仅对当前 step 生效）
校验失败（checksum mismatch）或 zip: not a valid zip file？缓存污染优先于网络排查
这类错误 90% 不是网络问题，而是模块缓存损坏或 GOSUMDB 不可达造成的“假失败”。
处理顺序很关键：
- 先运行
go clean -modcache清掉整个缓存（别只删子目录） - 临时关校验验证：在当前命令前加
GOSUMDB=off，例如GOSUMDB=off go mod download - 如果关了就通，说明是 sum.golang.org 访问问题；生产环境应换可信校验源，而非长期关 GOSUMDB
- 若某模块反复报 zip 错误，直接删对应缓存路径（如
$GOMODCACHE/github.com/some/pkg@v1.2.3）
私有云里最易被忽略的一点：代理配置和私有域名单必须在所有环节同步——本地开发、IDE 终端、CI 脚本、Docker 构建阶段，缺一不可。漏掉任一环，都可能让 go mod tidy 在某个环境里突然静默失败。
