根本原因是Go默认仅用不稳定的proxy.golang.org且无自动降级机制；应配置GOPROXY="https://goproxy.cn,direct"或"https://goproxy.cn,https://proxy.golang.org,direct"实现可靠fallback，避免使用已停服的goproxy.io。
为什么 go mod download 总是卡在某个模块上？
根本原因不是网络差，而是 Go 默认只用官方 proxy（proxy.golang.org），而它在国内访问不稳定，且不支持自动 fallback。一旦超时，Go 不会尝试其他源，直接报错退出——这不是重试机制缺失，是设计上就不支持降级。
配置 GOPROXY 实现自动降级的两种可靠写法
Go 1.13+ 支持用逗号分隔多个 proxy 地址，遇到第一个失败就自动切到下一个。关键在于顺序和可用性：
-
go env -w GOPROXY="https://goproxy.cn,direct"—— 国内镜像优先，失败后直连（direct表示跳过 proxy，走原始域名） -
go env -w GOPROXY="https://goproxy.cn,https://proxy.golang.org,direct"—— 多加一层兜底，但注意proxy.golang.org在国内大概率仍超时，所以放第二位更合理
不要写成 https://goproxy.cn,https://goproxy.io,direct：后者已停止维护，返回 404 会拖慢整个流程。
go mod download 超时时间不可调，但能绕过
Go 没有提供 -timeout 这类参数控制单个模块拉取时限。所谓“超时”其实是底层 HTTP 客户端默认 30 秒无响应即断开，且无法通过环境变量或命令行修改。
立即学习“go语言免费学习笔记（深入）”；
- 真正有效的缓解方式是：确保
GOPROXY链路中至少有一个可用节点，避免卡死 - 如果必须直连（比如私有模块），可提前用
git clone手动拉到$GOPATH/pkg/mod/cache/vcs/对应目录，Go 会优先复用本地缓存 - 禁用 proxy 的临时方案是
GOPROXY=direct go mod download，但仅限调试，别长期用
私有模块和 replace 场景下 proxy 会失效
当 go.mod 里用了 replace example.com/foo => ./local-foo 或 replace example.com/foo => git@github.com:org/foo.git，Go 会完全绕过 GOPROXY，直接走本地路径或 Git 协议。
- 此时超时来自 Git SSH/HTTPS 连接，和 proxy 配置无关
- 若用 SSH，检查
~/.ssh/config是否配了正确的 Host 和 ProxyCommand - 若用 HTTPS，可设
GIT_TERMINAL_PROMPT=0避免卡在凭证输入
proxy 降级只管「公共模块拉取」这一环，私有依赖链路得单独治理。
