Go 程序里 net.LookupHost 返回空或超时，先看 resolv.conf 是否被容器/沙箱覆盖
Go 的 DNS 解析默认走系统 libc（Linux）或系统 API（macOS/Windows），但一旦用 go build -ldflags="-linkmode external" 或运行在某些容器中（如 distroless、Alpine + musl），就会 fallback 到 Go 自己的纯 Go 解析器——它只读 /etc/resolv.conf，且不支持 search 域拼接、不读 options timeout:。
常见错误现象：net.LookupHost("redis") 成功，但 net.LookupHost("redis.default.svc.cluster.local") 失败；或本地能 nslookup 通，Go 程序却卡住 5 秒后报 no such host。
- 检查运行时实际读的文件：
strace -e trace=openat,open -f ./your-binary 2>&1 | grep resolv - 容器中务必挂载真实
/etc/resolv.conf，避免被精简镜像自动生成的空文件覆盖 - Alpine 镜像需额外安装
ca-certificates（影响 TLS 握手，间接导致 HTTPS 请求失败，常被误判为 DNS 问题）
调试时别只信 dig，要用 go run -gcflags="-m" main.go 确认解析路径
Go 在编译期就决定用 libc 还是 pure-Go 解析器：如果目标平台有 cgo 且未禁用，优先走 libc；否则硬切到 Go 实现。但 cgo 状态容易被隐式改变——比如设置了 CGO_ENABLED=0，或交叉编译时没配好 CC。
直接运行 dig redis.example.com 成功，不代表 Go 程序能成功，因为两者走的解析链路完全不同。
立即学习“go语言免费学习笔记（深入）”；
- 加
-gcflags="-m"编译，输出里出现"using netgo"表示走纯 Go 解析器；出现"using libc"表示走系统解析 - 临时强制走 libc 测试：运行前设
CGO_ENABLED=1，并确保LD_LIBRARY_PATH包含对应 libc 路径（容器中尤其注意） - 纯 Go 模式下无法使用
systemd-resolved的127.0.0.53，必须指向真实 upstream DNS（如8.8.8.8）
net.DefaultResolver 的 PreferGo 和 StrictErrors 不是开关，是行为微调点
很多人以为设 net.DefaultResolver.PreferGo = true 就能“强制用 Go 解析”，其实它只在 cgo 可用时起作用；而 StrictErrors 控制的是对 NXDOMAIN 的响应方式——true 时返回具体错误，false 时可能静默返回空结果，加剧排查难度。
典型误用场景：K8s 中 Pod 启动时依赖某 headless Service 域名，但 PreferGo=true + /etc/resolv.conf 里只有 cluster.local search 域，纯 Go 解析器不会自动补全，直接返回失败。
- 修改
DefaultResolver必须在程序启动早期做（main 函数开头），且不能并发修改 - 想绕过 search 域限制？手动拼完整域名再查，比如把
"redis"改成"redis.default.svc.cluster.local."（末尾点号表示绝对域名） -
StrictErrors=false下，LookupTXT等非 A/AAAA 查询可能返回空切片而不报错，需主动检查len() == 0
Go 1.19+ 的 net.Resolver 超时控制仍受限于底层系统调用
Resolver.Timeout 字段看起来能控制单次查询耗时，但它只约束 Go 解析器内部逻辑（比如重试间隔、TCP 连接建立），对 libc 调用完全无效——后者由系统 resolv.conf 的 timeout 和 attempts 决定，Go 无法干预。
现象：设了 Timeout: 100 * time.Millisecond，但实际卡住 5 秒，大概率是 libc 模式下系统默认尝试 3 次、每次超时 2 秒。
- 验证是否生效：用
strace观察是否有connect()或sendto()调用，以及间隔时间 - 真正可控的超时方案：用
context.WithTimeout包裹整个LookupHost调用，而不是依赖Resolver.Timeout - 高频查询场景（如服务发现轮询），建议复用
*net.Resolver实例，避免每次新建触发 DNS 缓存重建
Go 的 DNS 问题最麻烦的地方不在代码写法，而在运行时环境和编译模式的隐式耦合——同一份代码，在本地、CI、K8s、Lambda 上可能走四条完全不同的解析路径。盯住 CGO_ENABLED、/etc/resolv.conf 内容、strace 输出这三点，比翻文档快得多。
