net.LookupHost返回空切片加非nil error意味着DNS链路中断而非域名无A记录，常见于/etc/resolv.conf缺失、nameserver不可达或UDP被防火墙拦截，须同时检查err!=nil和len(ips)==0。
net.LookupHost 返回空切片 + 非 nil error 到底意味着什么
它不是“域名没 A 记录”，而是 DNS 链路大概率断了。常见现象：no such host、lookup xxx: no such host 或直接卡住几秒后报错。错误根源通常是：/etc/resolv.conf 不存在（Alpine/distroless 镜像）、nameserver 是 127.0.0.11（Docker 默认）但宿主机没跑 DNS 服务、musl libc 跳过 /etc/hosts、UDP 包被防火墙丢弃。
必须同时判断两个条件：err != nil 和 len(ips) == 0。只看切片长度会把网络故障当成“无记录”；只看 error 又可能忽略 CNAME 重试失败等边界情况。
-
err != nil且len(ips) > 0：极少见，但某些 resolver 实现可能返回部分结果加 warning -
err == nil且len(ips) == 0：合法但罕见，表示域名存在但无 A 记录（比如只有 AAAA） -
err != nil且len(ips) == 0：绝大多数生产环境的失败场景，应归为“解析不可用”，而非业务逻辑错误
怎么真正控制超时，而不是假装用 context.WithTimeout
net.LookupHost 本身不接受 context.Context，默认走系统 resolver（glibc/musl），超时由 OS 级配置决定（glibc 默认 5 秒 × 3 次重试）。传 context.WithTimeout 给它完全无效。
正确做法是换用自定义 *net.Resolver，并设 PreferGo: true —— 否则 Dial 函数不生效，Timeout 形同虚设：
立即学习“go语言免费学习笔记（深入）”；
resolver := &net.Resolver{
PreferGo: true,
Dial: func(ctx context.Context, network, addr string) (net.Conn, error) {
d := net.Dialer{Timeout: 2 * time.Second}
return d.DialContext(ctx, network, "8.8.8.8:53")
},
}注意：addr 别写成 "127.0.0.11:53"（Docker 内置 DNS），也别依赖 net.DefaultResolver，它不响应 context。
- 必须同时支持
"udp"和"tcp"协议，因为大响应会 fallback 到 TCP - 同一个
*net.Resolver实例不能跨 goroutine 动态改Dial，它是非并发安全的 - 在 Alpine 容器里，
PreferGo: true是刚需，否则 musl 可能连/etc/resolv.conf都不读
并发查多个域名时，为什么裸写 goroutine 是陷阱
写 for range hosts { go func() { net.LookupHost(...) }() } 看似高效，实则危险：任一域名卡住或失败，整个批次无法中断，没法统一超时，也没法聚合错误。
正确解法是用 errgroup.Group 配共享 context.Context：
eg, ctx := errgroup.WithContext(context.WithTimeout(context.Background(), 3*time.Second))
for _, host := range hosts {
host := host
eg.Go(func() error {
ips, err := resolver.LookupHost(ctx, host)
if err != nil {
return fmt.Errorf("lookup %s: %w", host, err)
}
// 处理 ips
return nil
})
}
if err := eg.Wait(); err != nil {
// 任一失败，全部取消
}这比手动 channel + select 更简洁，且天然支持 cancel propagation。
- 别用
WaitGroup+time.After模拟超时，它无法真正中断底层 resolver 调用 - 高并发下需加限速（如 semaphore），否则容易触发本机端口耗尽或被上游 DNS 限流（Cloudflare 对单 IP QPS 有硬限制）
- 如果只是做健康检查，建议加 TTL 缓存 +
singleflight.Group防击穿，避免重复查同一域名
net.LookupHost 和 net.LookupIP / net.LookupIPv4 的关键区别
net.LookupHost 返回 []string，只含 IPv4 字符串（如 "192.0.2.1"），不区分协议族，也不保证顺序；net.LookupIP 返回 []net.IP，含 IPv4 和 IPv6，可直接喂给 net.Dial；net.LookupIPv4（Go 1.22+）返回 []*net.IPAddr，专为 IPv4 设计，省去手动过滤成本。
对 "localhost"：LookupHost 通常只返 "127.0.0.1"，LookupIP 会同时返 127.0.0.1 和 ::1；对带端口的字符串（如 "example.com:443"），LookupHost 会当完整主机名查，必然失败。
- 需要连接双栈服务时，优先用
net.LookupIP - 仅做快速 ping 或日志打点，
net.LookupHost更轻量 - 只要 IPv4 且 Go ≥ 1.22，用
net.LookupIPv4最干净，不用ip.To4() != nil过滤 -
net.LookupHost查不到 CNAME 记录，它只返回最终 A/AAAA 地址；要获取别名链，得用net.LookupCNAME
最易被忽略的一点：在容器或 CI 环境里，net.LookupHost 行为高度依赖底层 libc 和 /etc/resolv.conf，而 net.LookupIP 在 PreferGo: true 下更稳定——Go 自己实现的 resolver 不吃 musl/glibc 差异的亏。
