go模块下载卡在proxy.golang.org或超时，根本原因是http_proxy/https_proxy等系统代理环境变量残留，即使goproxy设为direct，go仍会继承并尝试连接；须彻底清空所有大小写变体的代理环境变量，并同步设置goproxy=direct、gosumdb=off、goinsecure（调试用）方可解决。
Go模块下载卡在 proxy.golang.org 或直接超时
这是系统代理残留最典型的症状：明明没开代理，go get 却反复尝试连接 proxy.golang.org 或 sum.golang.org，最终超时或返回 403 Forbidden。根本原因不是 Go 本身有问题，而是环境变量或配置文件里还躺着旧的代理设置，Go 工具链会无条件继承它们。
-
HTTP_PROXY和HTTPS_PROXY环境变量（包括大小写变体如http_proxy）必须清空，哪怕值为空字符串也会触发代理逻辑 -
go env -w GOPROXY=direct只是覆盖 Go 的代理配置，压不住底层 HTTP 客户端对系统级代理变量的读取 - Windows 用户尤其要注意 PowerShell 的
$env:HTTP_PROXY和 CMD 的set HTTP_PROXY=可能不同步，需分别检查
验证代理变量是否真被清除了
别信“我刚才关了代理软件”这种直觉。要手动确认所有 shell 环境里这些变量确实不存在：
- Linux/macOS：运行
env | grep -i proxy，输出应为空；再检查~/.bashrc、~/.zshrc、/etc/environment里有没有残留的export HTTP_PROXY=... - Windows CMD：运行
set proxy，看是否列出任何含PROXY的变量；PowerShell 运行Get-ChildItem Env: | Where-Object Name -like "*proxy*" - IDE（如 VS Code）可能缓存旧环境，重启 IDE 或在终端里用
go env | grep -i proxy确认GOPROXY和GOSUMDB是否为direct或off
强制绕过所有代理层的终极方案
如果清理环境变量后仍不稳定，说明某些 Go 包（比如 golang.org/x/...）在内部 HTTP 客户端初始化时仍会读取系统代理策略。这时得从 Go 自身配置入手：
- 执行
go env -w GOPROXY="direct"（注意引号，避免 shell 解析错误） - 执行
go env -w GOSUMDB="off"，避免校验时连sum.golang.org - 执行
go env -w GOINSECURE="golang.org"，让 Go 对该域名跳过 TLS 验证（仅限调试，生产慎用） - 临时测试：加
-v参数跑go list -m -u all，观察日志里是否还有proxy.golang.org字样 —— 没有才说明生效
CI/CD 或 Docker 构建中代理残留更隐蔽
CI 脚本或 Dockerfile 里常通过 ENV HTTP_PROXY=... 设置代理，即使构建阶段已删，镜像层仍保留。后果是容器内 go mod download 依然走代理：
- Docker 构建时，在
RUN go mod download前加一行ENV HTTP_PROXY="" HTTPS_PROXY="" NO_PROXY="" - GitHub Actions 中，确保
steps里没有全局env:块注入代理变量，尤其警惕第三方 action 的隐式设置 - Kubernetes Pod 启动容器前，检查
pod.spec.containers[].env是否继承了集群级 ConfigMap 注入的代理变量
代理残留不是网络问题，是配置污染。只要有一处没清干净，Go 就会照单全收 —— 它不区分“你是不是真想用代理”，只认环境变量和配置项的字面值。
