确认go mod download卡在DNS解析阶段，需观察go mod download -v最后几行输出：若停在GET https://proxy.golang.org/...后无HTTP状态码且数秒无日志，则大概率是DNS卡住；此时复制URL用curl -v测试，若curl也卡在Resolving则证实DNS问题，否则为Go纯Go解析器行为差异。
go mod download卡在DNS解析阶段怎么确认？
不是看报错文字，而是用go mod download -v观察最后几行输出。如果停在类似GET https://proxy.golang.org/github.com/some/pkg/@v/v1.2.3.info之后、没返回HTTP状态码，且几秒内无后续日志，基本就是DNS卡住——Go的纯Go DNS解析器在私有网络里常因缺少上游DNS或配置错误而阻塞，且不响应Ctrl+C。
快速验证：复制那条GET URL，用curl -v手动执行。若curl也卡在Resolving，说明是DNS问题；若curl能解析但go不能，就是Go默认解析器行为差异。
- 私有网络常见现象：
/etc/resolv.conf为空、指向127.0.0.11（Docker内置DNS）、或只配了不可达的内网DNS - Alpine镜像或K8s Pod里，
net.DefaultResolver大概率静默失败，不报错也不返回结果 - 别依赖
nslookup或dig——它们走系统glibc resolver，Go用的是自己的纯Go实现，行为不同
GOPROXY=off后仍无法下载？检查GOSUMDB是否同步关闭
GOPROXY=off只是关掉模块下载代理，但Go仍会尝试连接sum.golang.org校验checksum。私有网络里这个域名同样无法解析，导致go mod download卡在verifying github.com/xxx@v1.2.3阶段，现象和DNS卡住一模一样。
必须同时执行：
立即学习“go语言免费学习笔记（深入）”；
go env -w GOPROXY=offgo env -w GOSUMDB=off
验证命令：go env GOPROXY GOSUMDB应输出off off。漏掉GOSUMDB=off是离线环境最常踩的坑——很多人以为关了代理就万事大吉，结果还是卡住。
离线缓存必须提前在联网机器上完整生成
Go模块缓存不是“按需拉取”，go mod download本质是批量写入$GOMODCACHE目录。离线机器上这个目录只是只读仓库，没有联网能力。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
正确操作顺序：
- 在能联网的机器上，确保
go.mod已干净（go mod tidy无报错） - 运行
go mod download，再用go list -m -f '{{.Dir}}' all | head -n 3随机检查几个模块路径是否存在 - 用
go env GOMODCACHE确认真实路径，打包整个目录（不是软链接） - 解压到离线机相同路径，且
go env GOPATH必须一致，否则Go找不到缓存
注意：go clean -modcache在离线机上没用——它清的是空目录，下次go mod download仍会卡在DNS。
企业内网有自建DNS时，强制Go用系统解析器
如果私有网络已部署可靠DNS（如BIND或CoreDNS），但Go仍解析失败，是因为它默认启用纯Go DNS解析器，绕过了/etc/resolv.conf。
临时生效（仅当前命令）：
GODEBUG=netdns=cgo go mod download
原理：cgo模式让Go调用系统glibc resolver，走/etc/resolv.conf配置。验证方式：加-v参数后，日志中会出现resolving via system DNS字样。
长期方案：在内网部署athens或goproxy服务，并监听0.0.0.0:3000（不是127.0.0.1），再设GOPROXY=http://intranet-proxy:3000——这样既避开DNS，又保留校验能力。
