go模块下载卡在dns解析阶段的根本原因是本地isp dns污染导致域名解析错误，解决方法是强制go使用系统dns（godebug=netdns=cgo）或更换可信dns（如8.8.8.8），并验证goproxy.cn等域名是否解析到正确cloudflare ip。
go mod download 卡在 DNS 解析阶段
这不是代理没配好，而是 Go 工具链在解析 proxy.golang.org 或模块源域名时，被本地 ISP 的 DNS 污染返回了错误 IP（比如指向 127.0.0.1 或不可达地址），导致 dial tcp xxx:443: connect: connection refused 或长时间无响应。
Go 默认用纯 Go 实现的 DNS 解析器（net.DefaultResolver），它不读系统 /etc/resolv.conf 的 timeout 配置，也不自动 fallback 到备用 DNS，遇到污染就卡死——且不响应 Ctrl+C，直到超时（默认几十秒）。
- 验证是否 DNS 问题：运行
go mod download -x github.com/gin-gonic/gin@v1.9.1，看最后一条 curl 命令的 URL 是否能用curl -v https://goproxy.cn/...手动跑通；如果手动 OK 但 go 命令卡住，基本就是 DNS 层面被劫持 - 临时绕过：执行
go env -w GODEBUG=netdns=cgo，强制 Go 使用系统 libc 的 DNS 解析逻辑（会读取/etc/resolv.conf，支持 timeout 和 nameserver fallback） - 更稳的做法：改用可信 DNS，比如在终端里先设
export SYSTEMD_RESOLVED=1（Linux）或直接改系统网络设置为8.8.8.8/1.1.1.1，再启动终端运行 Go 命令
GOPROXY 设对了但还是连不上 goproxy.cn
设置了 GOPROXY=https://goproxy.cn,direct，go env GOPROXY 也显示正确，但 go mod download 仍报 dial tcp: i/o timeout —— 这大概率不是代理本身挂了，而是你的 DNS 把 goproxy.cn 解析到了错误 IP，或者中间网关（如企业防火墙、路由器）做了 HTTPS 拦截/重定向。
国内部分宽带运营商会对 CDN 域名做本地缓存劫持，goproxy.cn 走的是 Cloudflare CDN，某些地区会返回 502 或空响应。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 快速验证：在终端里执行
dig +short goproxy.cn或nslookup goproxy.cn，看返回的 IP 是否属于 Cloudflare（如104.21.36.195、172.67.132.219等）；如果不是，说明 DNS 污染已发生 - 临时对策：把
GOPROXY改成 IP 直连（不推荐长期用，但可验证）：go env -w GOPROXY=https://104.21.36.195:443,direct（注意保留:443和,direct） - 根治建议：换用非 CDN 域名的镜像，例如清华源
https://mirrors.tuna.tsinghua.edu.cn/go/modules/，它走的是教育网直连，DNS 污染概率低得多
私有模块拉取失败并伴随 DNS 错误
当你配置了 GOPRIVATE=git.internal.company，但 go mod download 仍卡在解析 git.internal.company 上，甚至报 lookup git.internal.company: no such host，这说明 Go 在跳过代理后，仍用被污染的 DNS 去查你内网域名。
这不是 GOPRIVATE 没生效，而是 DNS 层面根本查不到这个域名——尤其在 WSL、Docker 或某些笔记本 WiFi 环境下，/etc/resolv.conf 里的 nameserver 可能是 127.0.0.1（指向 host 侧的 dnsmasq 或 systemd-resolved），而该服务本身又被 ISP 劫持。
- 检查真实 DNS：在终端运行
cat /etc/resolv.conf，确认nameserver行指向的是你可控的 DNS（如公司内网 DNS 或114.114.114.114） - 强制指定 resolver：启动 Go 命令前加环境变量
GODEBUG=netdns=cgo，确保它走系统 DNS；若仍不行，可在公司内网部署一个轻量 DNS 转发器（如 CoreDNS），把git.internal.company显式指向内网 IP - 避免依赖 DNS：对关键私有模块，在
go.mod中用replace硬编码本地路径或 SSH 地址，绕过域名解析环节
go clean -modcache 后反而更慢
清空模块缓存后，go mod download 不仅没变快，还频繁出现 verifying ...: checksum mismatch 或反复重试同一个模块——这是因为 DNS 污染导致 Go 从不同镜像源拿到同一模块的不同哈希，而 sum.golang.org 校验服务器又不可达，工具链陷入无限 fallback 循环。
此时 go clean -modcache 不是解药，而是放大了 DNS 不一致带来的校验混乱。
- 先停掉校验干扰：临时执行
go env -w GOSUMDB=off（仅限调试，勿提交） - 再清理并重试：运行
go clean -modcache && go mod download -v，观察是否所有模块都从你设定的GOPROXY拉取（日志里应只出现GET https://goproxy.cn/...） - 恢复校验前务必确认 DNS 正常：否则
GOSUMDB=off关太久，上线后可能因哈希不匹配导致构建失败
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
