go mod download卡住时重试由net/http Transport自动触发，非Go工具链主动控制；仅对网络错误（如超时、DNS失败）指数退避重试，404/403等HTTP状态码不重试，真正可控的是代理链配置与GONOPROXY精准排除。
go mod download 卡住时，重试到底由谁触发？
不是 Go 工具链主动“重试”，而是底层 HTTP 客户端在连接失败、TLS 握手超时、DNS 解析失败等场景下自动发起重试 + 指数退避。你看到的“卡几秒后报错”，其实是 net/http 默认的 Transport 在反复尝试连接 proxy.golang.org，每次间隔拉长，最终超时抛出 dial tcp: i/o timeout。
关键点在于：这个重试行为无法关闭，也无法配置次数或间隔——它藏在 Go 标准库底层，且只对网络层错误生效；HTTP 状态码如 404、403、503 不会触发重试，而是直接失败。
- 真正能干预的只有代理路径：换掉不稳定的
https://proxy.golang.org，让请求更快成功，自然就绕过了重试过程 -
go mod download -x输出里如果出现多次GET https://proxy.golang.org/...尝试，说明重试已发生；若只出现一次就报错，大概率是 DNS 或防火墙拦截，而非重试逻辑本身 - 别指望靠
GOPROXY里的多个地址实现“重试”——Go 是顺序尝试，不是并发或轮询；https://goproxy.cn,https://mirrors.aliyun.com/goproxy/,direct这种写法，只有前一个返回 404 或 5xx 才会走下一个
GOPROXY 配置中 direct 的真实作用
direct 不是“重试兜底”，而是“跳过代理直连源站”的明确指令。它只在当前代理返回 404 Not Found 或 410 Gone（模块不存在）时触发，而不是任何网络错误都 fallback。
典型误用场景：把私有 Git 地址（如 git.internal.company.com/lib）写进 go.mod，却没配 GONOPROXY，结果 Go 仍尝试用 goproxy.cn 去查这个域名，返回 404，然后才走 direct ——这期间多了一次无效 HTTP 请求，还可能因认证缺失导致失败。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是提前用
go env -w GONOPROXY=git.internal.company.com排除，让 Go 从一开始就不走代理 -
direct对403 Forbidden无效：代理返回 403 说明它收到了请求但拒绝服务（比如权限不足），Go 不会 fallback，而是直接报错 - 如果你的私有模块用 SSH 地址（
git@git.internal.company.com:lib.git），direct也帮不上忙——Go 仍需调用git命令，此时依赖本地 SSH key 和 known_hosts 配置
如何验证重试是否真被绕过，而非静默失败？
别信 go env GOPROXY 的输出，那只是配置项；要确认实际行为，必须看运行时日志。
执行 go mod download -x github.com/gin-gonic/gin@v1.9.1，观察输出中每一条 GET 请求的 URL 和状态码：
- 看到
GET https://goproxy.cn/...+200 OK→ 代理生效，无重试 - 看到
GET https://proxy.golang.org/...→GOPROXY没生效，或被 IDE/Shell 环境覆盖 - 看到多次
GET https://goproxy.cn/...+404→ 模块在镜像站缓存未就绪，direct尚未触发（因 404 不触发 fallback） - 看到
git clone ssh://...或git ls-remote https://...→ 当前模块被判定为私有，已跳过代理
注意：加 -x 后若输出极短（仅一两行），大概率是模块已缓存，根本没发网络请求——先删 $GOMODCACHE 下对应目录再试。
私有模块 + 代理混合场景下的重试陷阱
当项目同时引用公开模块（走代理）和私有模块（需 GONOPROXY），最容易踩的坑是间接依赖引发的“隐式私有路径”。比如 A 依赖 B，B 的 go.mod 里写了 replace private-lib => git.internal.company.com/lib v0.0.0-...，但你的项目没配 GONOPROXY，Go 在解析 B 的依赖时仍会尝试代理访问 git.internal.company.com，结果卡住或 403。
这种问题不会出现在 go list -m all 的顶层依赖里，得靠 go mod graph | grep internal 或 go mod vendor -v 暴露。
- 解决方案不是加更多重试，而是补全
GONOPROXY：覆盖所有可能出现在依赖树里的私有域名 -
GONOSUMDB必须与GONOPROXY完全一致，否则 Go 会在校验阶段再次尝试访问 sum server，导致二次失败 - 临时诊断可用
GOPROXY=direct go mod download -v强制全直连，若此时成功，说明问题一定出在代理链路或GONOPROXY漏配
最麻烦的不是配置本身，而是私有模块的版本标识（如 v0.0.0-20230101000000-abc123）一旦被公开模块间接引用，就会把整个依赖树拖入代理 fallback 逻辑——这种隐式耦合，比显式 require 更难排查。
