go 的 net.lookuphost 默认使用系统解析器，易因容器或 dns 配置异常返回 no such host；应改用 net.resolver 显式指定 dns 服务器并设置超时，注意 prefergo 行为差异及 fqdn 要求。
LookupHost 返回空结果或报错 no such host
Go 的 net.LookupHost 默认走系统解析器（通常是 /etc/resolv.conf），不是直连 DNS 服务器。如果你在容器、自建网络或 DNS 配置异常的环境里调用它，很容易返回 no such host，哪怕 dig 或 nslookup 能查到。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先确认系统级 DNS 是否可用：
cat /etc/resolv.conf，检查 nameserver 是否可连（比如nc -u 8.8.8.8 53） - 避免依赖系统配置：改用
net.Resolver显式指定 DNS 服务器，例如&net.Resolver{PreferGo: true, Dial: dialFunc} - 注意 Go 版本差异：1.19+ 对
PreferGo: true的 UDP 截断处理更鲁棒；旧版本遇到 > 512B 响应可能静默失败
想绕过系统 resolver 直连 DNS 服务器
Go 标准库不提供裸 DNS 查询函数，但 net.Resolver 支持自定义 Dial，可以接管底层连接逻辑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
net.Dialudp构造一个固定 DNS 服务器的 dialer，比如指向1.1.1.1:53 - 务必设置超时：
ctx, cancel := context.WithTimeout(ctx, 3*time.Second)，否则默认无 timeout，卡死风险高 - 不要复用
*net.Resolver实例跨 goroutine 写字段（如修改Dial），它是非并发安全的；每个 resolver 实例应绑定单一用途 - 示例关键片段：
r := &net.Resolver{ PreferGo: true, Dial: func(ctx context.Context, network, addr string) (net.Conn, error) { return net.DialUDP("udp", nil, &net.UDPAddr{IP: net.ParseIP("1.1.1.1"), Port: 53}) }, }
查到 IP 却和 dig 结果不一致
net.LookupHost 和 dig 行为不同，常见原因不是 bug，而是语义差异：前者只返回 A/AAAA 记录（不含 CNAME 展开链），且不区分 TTL、不缓存、不处理重试策略。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 查 CNAME 需用
net.LookupCNAME单独调；LookupHost不会返回中间 CNAME，即使存在 - 同一域名多次调用
LookupHost可能拿到不同 IP（比如负载均衡 DNS），这不是 Go 的问题，是服务端返回的记录本身如此 - 若需完整响应（含 RCODE、TTL、所有 record 类型），得用第三方库如
miekg/dns发送原始 query；net包只做“解析出 IP”这一件事
在 CGO 禁用环境下 DNS 解析失败
当编译时加了 -tags netgo 或 CGO_ENABLED=0，Go 强制使用纯 Go resolver（PreferGo: true），此时不读取 /etc/nsswitch.conf，也不调 libc getaddrinfo，但对某些 DNS 配置（如 search domain、ndots）支持较弱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保传入
LookupHost的域名是 FQDN（以.结尾），比如"example.com."，避免依赖 search 域补全 - 禁用 CGO 后，
/etc/resolv.conf仍会被读，但忽略options ndots:5这类配置；如有需要，手动拼接 search 域 - 交叉编译到嵌入式平台（如 arm64 Alpine）时，优先验证
resolv.conf路径是否真实存在——Alpine 默认没有该文件，需显式挂载或写入
Go 的 DNS 解析看似简单，但实际踩坑点集中在「谁在解析」「怎么超时」「要不要展开别名」这三处。最容易被忽略的是：它从不告诉你当前走的是 libc 还是 Go 自研 resolver，而两者的错误表现和调试路径完全不同。