Go 1.19+ 默认启用 cgo DNS 解析器，若系统 glibc 版本低于 2.17（如 CentOS 6 或旧 Alpine），getaddrinfo 可能无限阻塞，导致 net/http 请求卡在 DNS 阶段；临时验证可设 GODEBUG=netdns=go 强制纯 Go 解析，根本解法是构建时设 CGO_ENABLED=0 并确保 /etc/resolv.conf 中 timeout 和 attempts 合理。
Go 1.19+ 默认启用 cgo 的 DNS 解析器，但系统 glibc 版本太低会直接卡住
Go 在 1.19 后默认开启 cgo DNS 解析（即调用系统 getaddrinfo），不再 fallback 到纯 Go 实现。如果宿主机的 glibc 版本低于 2.17（如 CentOS 6、某些 Alpine 旧镜像或定制精简系统），getaddrinfo 可能因缺少 AI_ADDRCONFIG 支持或 NSS 模块异常而无限阻塞，表现为 net/http 请求卡在 DNS 阶段，超时前无错误日志。
- 验证方式：运行
ldd --version查看 glibc 版本；若低于 2.17，基本可锁定根源 - 临时验证：启动时加环境变量
GODEBUG=netdns=go，强制走纯 Go 解析器，若问题消失即证实是 cgo DNS 问题 - 注意：Alpine 使用 musl libc，不走 glibc 路径，但若用
alpine:3.14及更早版本，musl 的getaddrinfo有已知 deadlock bug，同样需规避
如何强制禁用 cgo DNS 并确保生效
不能只靠 GODEBUG=netdns=go —— 它仅影响运行时行为，且在某些 Go 版本中会被构建时设定覆盖。真正可靠的方式是在构建阶段切断 cgo 依赖：
- 编译前设置
CGO_ENABLED=0，例如：CGO_ENABLED=0 go build -o myapp . - 若使用 Docker，Dockerfile 中必须显式声明：
ENV CGO_ENABLED=0，且放在FROM之后、RUN go build之前 - 检查是否生效：用
file myapp确认输出含statically linked；或运行ldd myapp应提示not a dynamic executable - 警告：若代码中调用了
C.xxx或依赖了net以外需 cgo 的包（如os/user），CGO_ENABLED=0会导致构建失败，需一并处理
排查时别忽略 /etc/resolv.conf 的 timeout 和 attempts 设置
即使启用了纯 Go DNS 解析器，它仍会读取系统 /etc/resolv.conf。若该文件里配置了过长的 timeout 或过多 attempts（比如 options timeout:5 attempts:5），单次 DNS 查询可能耗时高达 25 秒，叠加 Go 默认的 net.DialTimeout（30s），极易触发超时且难以定位。
- 查看当前配置：
cat /etc/resolv.conf，重点关注options行 - 推荐值：
options timeout:1 attempts:2，既防瞬时丢包，又避免长等 - Docker 场景下特别注意：容器启动时若未指定
--dns，会继承宿主机resolv.conf，而宿主机可能配置了内网慢 DNS 或已失效的 nameserver - 验证 DNS 响应时间：
dig google.com +short @8.8.8.8，对比直接查本地 nameserver 的耗时
Go 的 net.DefaultResolver.Timeout 不是全局开关
很多人以为改了 net.DefaultResolver.Timeout 就能统一控制所有 DNS 查询，但实际上它只影响显式调用 net.DefaultResolver.LookupHost 等方法的场景。HTTP Client、database/sql 连接字符串解析、甚至 net/http.Transport 的底层 dial 都绕过这个设置，各自走自己的逻辑路径。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 场景下，DNS 超时由
net/http.Transport.DialContext控制，需自定义net.Dialer并设Timeout和KeepAlive - 示例关键片段：
dialer := &net.Dialer{ Timeout: 2 * time.Second, KeepAlive: 30 * time.Second, } transport := &http.Transport{ DialContext: dialer.DialContext, } - 根本解法仍是优先确保 DNS 解析本身不卡——要么用纯 Go 解析器，要么确认系统库和 resolv.conf 可靠；超时设置只是兜底，不是病因
真正麻烦的从来不是“怎么设超时”，而是“为什么 DNS 查询根本没返回”。系统网络库版本不匹配的问题，往往藏在 strace -e trace=connect,sendto,recvfrom 的 syscall 卡点里，而不是日志里。
