Go Modules下载慢的根本原因是默认直连境外源导致DNS污染、超时及TLS失败；解决方法是设置GOPROXY为https://goproxy.cn,direct并用go env -w写入全局配置。
go mod download 被墙导致超时
国内直接运行 go mod download 或 go build 时，常因无法访问 proxy.golang.org 或 goproxy.io 等默认代理而卡在“Fetching”阶段，表现为 Get "https://proxy.golang.org/..." 超时或 context deadline exceeded。
- 临时解决：执行
go env -w GOPROXY=https://goproxy.cn,direct（推荐国内镜像） - 验证是否生效：运行
go env GOPROXY，输出应为https://goproxy.cn,direct - 若仍失败，检查是否被公司代理或防火墙拦截——可尝试加
-v参数看具体卡在哪一步：go mod download -v - 注意：不要只设
GOPROXY=https://goproxy.cn，漏掉,direct会导致私有模块（如 internal 或 gitlab 私仓）拉取失败
go get 安装工具时连接超时（如 gopls、dlv）
go get 默认走 global proxy，但部分工具（尤其是带 golang.org/x/ 路径的）会绕过 GOPROXY，直连 golang.org，而该域名在国内基本不可达。
- 改用
GO111MODULE=on go install替代go get（Go 1.16+ 推荐方式） - 例如安装
gopls：GO111MODULE=on go install golang.org/x/tools/gopls@latest - 若仍超时，手动替换模块路径：把
golang.org/x/tools改成github.com/golang/tools（需同步改 import，仅调试用） - 更稳妥的做法是配好 GOPROXY 后，再加环境变量
go env -w GONOPROXY="gitlab.example.com,192.168.0.0/16"，避免私有域名也被代理
go run / go build 卡在 DNS 或 dial 阶段
不是网络请求超时，而是 Go 工具链自身在解析模块路径或校验 checksum 时，底层 net.Dial 未设 timeout，遇到 DNS 慢或中间网关丢包，可能阻塞数十秒甚至更久。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 这不是代码问题，是 Go CLI 的行为——它不响应 Ctrl+C 直到 dial 完成，容易误判为“死锁”
- 快速验证：执行
go mod download -x查看最后一条 curl 命令，复制出来手动跑，看是 DNS 还是 connect 超时 - 临时缓解：加
go env -w GODEBUG=netdns=cgo强制用系统 DNS，避开 Go 自带的纯 Go DNS 解析器（有时更慢） - 根本解法：确保
GOPROXY可达，并在企业内网部署私有 proxy（如 Athens），避免对外依赖
本地 GOPROXY 服务启动失败导致超时
如果你自建了 athens 或 goproxy 服务，但 go mod 仍超时，大概率是服务没起来，或监听地址没暴露给 Go CLI。
立即学习“go语言免费学习笔记（深入）”；
- 确认服务监听的是
0.0.0.0:3000而非127.0.0.1:3000（Docker 或 WSL 场景下尤其关键） - 检查防火墙：
sudo ufw status或iptables -L，确保端口开放 - 测试连通性：
curl -v http://localhost:3000/github.com/golang/go/@v/list，返回 200 才算真正就绪 - Go CLI 不支持带认证的 proxy（如 Basic Auth），若你加了 auth 中间件，必须去掉或改用 token header 方式（需定制 proxy）
http.Client，也不读 context，只能靠环境变量和代理服务兜底。 
