go 1.21+ 默认 goproxy 是 https://proxy.golang.org,direct；因 proxy.golang.org 在国内访问极慢或超时，且 go 仅在网络连接失败时 fallback，不响应 http 错误码，导致 go mod download 卡住或报错。
Go 1.21+ 默认 GOPROXY 是什么，为什么你一开箱就卡住
Go 1.21 起，GOPROXY 默认值已从空字符串变成 https://proxy.golang.org,direct。这不是“没配”，而是配了一个在国内基本不可用的地址——proxy.golang.org 响应极慢或直接超时，且 Go 不会在收到 404/503 时 fallback 到 direct，只在网络连接失败（如 timeout）时才试下一个。结果就是：go mod download 卡在 “downloading …” 几分钟不动，最后报错退出。
- 必须显式覆盖
GOPROXY，不能依赖默认值 -
direct必须保留，但不能放最前、也不能单独写 - 多个代理地址之间用英文逗号分隔，不能有空格
- 推荐配置：
go env -w GOPROXY=https://goproxy.cn,https://mirrors.tuna.tsinghua.edu.cn/goproxy/,direct
为什么不能只写 goproxy.cn —— 单点故障的真实代价
看似 https://goproxy.cn 稳定，但实际生产中它会因 CDN 缓存未刷新、上游同步延迟、证书轮换等问题返回 404 Not Found。而 Go 的 fallback 逻辑只触发于网络层失败（connect refused / timeout），不响应 HTTP 状态码错误。一旦遇到 404，命令立刻终止，不会尝试 direct 或其他代理。
- 现象示例：
go: downloading example.com/v2 v2.1.0: reading https://goproxy.cn/example.com/v2/@v/v2.1.0.info: 404 Not Found - 单镜像配置 = 把构建稳定性押在一家 CDN 上
- 至少两个独立镜像（如清华 + 阿里云）+
direct才算兜底完整 - 企业内网 CI 中要移除
direct，但必须确保所有模块都能被代理命中（需配合GOPRIVATE和私有 proxy）
VS Code 里 GOPROXY 不生效？检查这三处地方
VS Code 启动的终端或任务可能不继承系统 shell 的环境变量，尤其 Windows 下 cmd/powershell 和 VS Code 内置终端常不同源。常见表现是：终端里 go env | grep GOPROXY 显示正确，但 go mod tidy 仍走默认代理。
- 先在 VS Code 终端里运行
go env GOPROXY确认是否生效 - Windows 用户：检查是否通过
setx GOPROXY "..."设置（需重启 VS Code）；macOS/Linux 用户：确认~/.zshrc或~/.bash_profile已 source，且 VS Code 是从终端启动的 - VS Code 的 Go 插件（如
gopls）有时会缓存旧配置，可尝试在命令面板执行Go: Restart Language Server - 不建议在
settings.json里用"go.toolsEnvVars"覆盖——它只影响插件调用的工具，不影响终端命令
Global Proxy 和 GOPROXY 根本不是一回事
“Global Proxy” 是非官方说法，常被误用于指代系统级 HTTP 代理（如 http_proxy）。而 GOPROXY 是 Go 模块专用的、语义明确的模块发现与下载协议代理，它不走 HTTP CONNECT 隧道，也不受系统 http_proxy 影响（除非你手动把它们设成一样）。混淆两者会导致：开了系统代理却仍下不了包，或关了系统代理后 GOPROXY 反而失效（比如某些代理软件劫持了所有 HTTPS 流量）。
立即学习“go语言免费学习笔记（深入）”；
-
GOPROXY地址必须是支持 Go module protocol 的服务（如返回/@v/list、/@v/v1.2.3.info的接口） -
http_proxy是底层 TCP 层代理，对GOPROXY请求起作用，但对direct回源（即直连 GitHub）也起作用——容易引发认证失败或 403 - 调试时可加
-v观察真实请求：go list -m -json -u all -v 2>&1 | grep 'proxy\|direct'
真正麻烦的从来不是配错一行命令，而是配对了却不知道它在哪一层被绕过——GOPROXY 在 go 命令、gopls、CI runner、Docker 构建阶段各自读取环境的方式都不同，漏掉任意一处，就会在某个环节突然断流。
