go mod download卡住不会自动重试，因Go工具链对单个模块仅发起一次HTTP请求，失败即报错退出；需手动加-x观察请求、shell循环重试或切direct验证，前提须正确配置GOPROXY含,direct及GOPRIVATE。
go mod download 卡住时为什么不会自动重试
Go 工具链默认对单个模块的下载请求只发一次，失败就报错退出，不会像 curl -retry 那样内置指数退避重试逻辑。这导致网络抖动（比如 TLS 握手超时、短暂 DNS 解析失败、CDN 节点临时不可用）直接中断整个 go mod download 或 go mod tidy 流程。你看到的 “卡在某个模块几秒不动然后报 dial tcp: i/o timeout”，本质是 Go 在等待单次 HTTP 请求返回，而非主动重试。
手动触发重试的三种可靠方式
别依赖 Go 自己重试，得自己控制流程：
- 加
-x参数观察真实请求地址，确认是否真卡在代理上：运行go mod download -x github.com/sirupsen/logrus@v1.14.0，看日志里是GET https://goproxy.cn/...还是GET https://proxy.golang.org/... - 用 shell 循环 + 状态码判断实现简单重试：
for i in {1..3}; do go mod download && break || sleep $((i * 2)); done每次失败后等 2s、4s、6s 再试，避免雪崩式重连 - 临时切到
GOPROXY=direct绕过代理直连源站（仅限小范围验证）：GOPROXY=direct go mod download—— 如果直连成功，说明问题出在代理链路，不是模块本身
避免重试失败的配置前提
重试再多次也救不回错误的环境配置：
-
GOPROXY必须设为可用地址且含,direct后缀，例如https://goproxy.cn,direct。缺了,direct，遇到代理 404 或 503 就彻底失败，无法 fallback -
GOPRIVATE必须覆盖所有私有域名，否则私有模块被转发到公有代理，返回 403 后 Go 不会重试，而是直接终止 - 不要设
GOSUMDB=off来“解决”校验失败——它只是掩盖问题。真正该做的是换可用的校验服务（如GOSUMDB=sum.golang.google.cn），或确保网络能通sum.golang.org
缓存损坏导致的“假中断”怎么识别
有时看起来像网络中断，其实是本地缓存已损坏，Go 读 zip 失败后不再尝试重新下载：
- 报错含
zip: not a valid zip file或invalid module，基本可判定缓存污染 - 定位损坏模块：错误信息里通常带路径，如
github.com/hashicorp/go-version，直接删对应缓存目录：rm -rf $GOPATH/pkg/mod/cache/download/github.com/hashicorp/go-version - 全量清理（慎用）：
go clean -modcache，但后续首次go mod download会变慢
重试机制本身很简单，难点在于分清是网络抖动、代理失效、私有路由错位，还是缓存已坏——每种情况对应的修复动作完全不同，混用反而让问题更难定位。
