根本原因是go默认直连被拦截的proxy.golang.org且无自动fallback，需配置goproxy=https://goproxy.cn,direct实现国内镜像优先、失败直连源站的可靠回退机制。
为什么 go mod download 总是超时？
根本原因不是网络慢，而是 Go 默认使用官方 proxy（proxy.golang.org）且不带 fallback 机制，一旦该域名被拦截或响应延迟，整个模块拉取就会卡在超时（默认 10 秒），且不尝试备用源。
常见现象：go mod download 卡住、go build 报错 Get "https://proxy.golang.org/...": dial tcp: i/o timeout，或者耗时远超预期（>30s）。
- 国内多数环境直连
proxy.golang.org不稳定，DNS 污染或路由绕行导致 TCP 握手失败 -
GO111MODULE=on且未显式配置 proxy 时，Go 会强制走官方 proxy，不退化到 direct - 即使设置了
GOPROXY，若值末尾没加,direct，遇到私有模块或不存在的包会直接失败，而非回退
如何正确设置 GOPROXY 多源 fallback？
必须用逗号分隔多个代理，并以 direct 结尾，否则私有仓库或本地 replace 会被跳过。
推荐配置（终端执行）：
go env -w GOPROXY=https://goproxy.cn,direct
这个组合意味着：先试国内镜像 goproxy.cn，失败后直接走源站（git clone），不经过 proxy；如果源站也不通，才报错——而不是卡死。
-
https://goproxy.cn支持完整语义化版本解析，缓存覆盖广，对github.com/golang.org/google.golang.org等主流模块响应快 - 避免用
https://mirrors.aliyun.com/goproxy/：它不支持/@v/list接口，会导致go list -m -versions类命令失败 - 若公司有私有模块，务必保留
direct在最后，否则replace或require ./local/path会失效
哪些情况不能只靠 GOPROXY？
当模块托管在 GitHub 私有仓库、GitLab 内网实例、或需要 SSH 认证的地址时，GOPROXY 无法处理认证和协议切换，必须配合 git config 和 GOINSECURE。
- 私有 GitHub：确保
git config --global url."git@github.com:".insteadOf "https://github.com/"已设置，否则go get仍走 HTTPS 并因 token 缺失失败 - 内网 GitLab：设
GOINSECURE=gitlab.example.com（跳过 TLS 验证），同时配git config将 HTTPS URL 映射为 SSH - 模块路径含非标准 host（如
mycorp.com/repo）：需在go.mod中用replace指向本地路径，或确保该域名能被go正确解析为 git 地址
临时调试：绕过 proxy 直接拉取某个模块
不用改全局配置，快速验证是否是 proxy 问题：
GOPROXY=direct go get github.com/sirupsen/logrus@v1.9.0
如果成功，说明问题出在 proxy 链路；如果仍失败，检查 git 凭据、网络连通性或模块是否存在。
-
GOPROXY=direct只影响当前命令，不影响后续操作 - 搭配
-v可看详细过程：GOPROXY=direct go get -v github.com/sirupsen/logrus - 注意：
direct模式下，Go 会尝试git clone，要求本地已配置好对应 host 的 SSH key 或 HTTPS token
真正麻烦的从来不是换一个镜像，而是混合了私有模块、SSH 认证、自签名证书和 GOPROXY fallback 逻辑——这几样只要漏掉一环，超时就变成“看起来随机但其实必现”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
