go mod download卡在proxy.golang.org超时是模块下载阶段网络不通所致，需配置GOPROXY=https://goproxy.cn,direct并同步设置GOSUMDB=off（测试）或可信校验源（生产），否则校验失败仍会中断构建。
go mod download卡在proxy.golang.org超时
这不是 Go 安装失败，而是模块下载阶段网络不通。Go 1.13+ 默认用 proxy.golang.org，国内直连基本都会卡住，现象是命令无响应、几秒后报 connection refused 或直接 hang 住。
临时验证是否代理问题：执行 go env -w GOPROXY=direct，再跑 go mod download——若仍失败，说明连源码仓库（如 GitHub）也访问不了，direct 模式无效。
- 生产环境别长期用
direct：它绕过代理但不解决校验问题，GOSUMDB仍会尝试连sum.golang.org，导致go build失败 - 推荐组合设置：
go env -w GOPROXY=https://goproxy.cn,direct+go env -w GOSUMDB=off（测试环境）或go env -w GOSUMDB=sum.golang.org（生产环境配可信代理） -
GOPROXY值末尾必须带,direct，否则私有模块（如gitlab.internal）会因 403/404 失败
GOPROXY 设置后 checksum mismatch 报错
现象是 verifying github.com/xxx@v1.2.3: checksum mismatch，本质不是代码被篡改，而是本地缓存、镜像同步延迟或 replace 规则冲突导致的校验失败。
- 先清缓存：
go clean -modcache，再重试go mod download；这能解决 70% 的误报 - 检查
go.mod里是否有replace指向本地路径但没删// indirect标记——这种残留会让 Go 误算校验和 - 临时绕过单个模块校验：
go get -insecure github.com/xxx/yyy，但别设全局GOINSECURE，否则私有域名全跳过校验，风险不可控
内网部署离线代理却漏配 GOSUMDB
搭了 athens 或 goproxy.cn 离线镜像，go mod download 成功了，但 go build 仍失败，错误日志里藏着 fetching sum.golang.org——这说明 GOSUMDB 没关或没指向内网校验服务。
立即学习“go语言免费学习笔记（深入）”；
-
GOSUMDB=off最简单，适合隔离网络环境；但上线前必须确认所有依赖已预审可信 - 若需保留校验，得部署内网
sum.golang.org镜像（如用goproxy的-sum模式），然后设go env -w GOSUMDB=https://goproxy.internal.company/sum -
GOPROXY和GOSUMDB必须同域或可互通，否则代理能拉代码、校验服务连不上，照样失败
CI 流程中 vendor 后仍校验远程 sum
go mod vendor 成功不代表构建就稳了。默认情况下，即使有 vendor 目录，Go 仍会连接远程校验服务器，除非显式禁用。
- CI 构建机必须设：
GOPROXY=direct GOSUMDB=off，再运行go build；只设GOPROXY不够 -
go mod vendor前务必先go mod tidy，否则vendor里可能混入已删模块，构建时触发校验逻辑 - 如果用了
replace或本地路径依赖，go mod vendor不会自动复制它们，需手动确保路径存在且可读
go env GOPROXY 和 go env GOSUMDB 双重确认输出值，再跑 go mod download -v 看最后一条 curl 请求是否命中预期地址——很多故障就卡在环境变量写错、shell 配置未 reload 或 Docker 容器里变量未透传这几个点上。 
