net.lookuphost 查不到 cname 记录，因为它只返回 a/aaaa 地址，底层调用 getaddrinfo(3) 属于地址解析而非 dns 记录查询，不暴露 cname 跳转过程；需用 net.lookupcname 等专用函数获取别名信息。
net.LookupHost 为什么查不到 CNAME 记录
因为 net.LookupHost 只返回 A/AAAA 地址，不解析别名链。它底层调用的是 getaddrinfo(3)，属于“地址解析”而非“DNS 记录查询”，CNAME 是 DNS 协议层的概念，Go 标准库这层接口不暴露中间跳转过程。
常见错误现象：对 www.example.com 调用 net.LookupHost 返回 192.0.2.1，但你其实想确认它是否指向 example.com. —— 这个信息被直接丢弃了。
- 如果需要 CNAME、TXT、MX 等任意记录类型，必须用
net.LookupCNAME（仅 CNAME）、net.LookupTXT等专用函数，或改用第三方库如miekg/dns -
net.LookupCNAME返回的是最终解析出的规范域名，不是原始响应里的 CNAME 字段值；若无 CNAME，它会返回输入域名本身 + nil error - 注意：CNAME 查询不保证后续 A 记录一定存在，
net.LookupCNAME成功 ≠net.LookupHost也会成功
net.LookupIP 和 net.LookupHost 的实际区别在哪
表面上都返回 IP 列表，但行为差异影响调试和兼容性判断：
-
net.LookupHost接收域名字符串，返回[]string（IP 字符串切片），内部自动处理 IPv4/IPv6 优先级、本地 hosts 文件、甚至 NSS 配置（Linux 上） -
net.LookupIP同样接收域名，但返回[]net.IP（原生 IP 结构体），更接近底层，适合后续做 IP 比较、掩码计算等操作 - 在容器或自定义 /etc/resolv.conf 环境中，
net.LookupHost可能因 glibc 行为差异出现缓存不一致，而net.LookupIP更稳定——Go 自己实现的 resolver 不依赖 libc - 性能上无显著差别，但
net.LookupIP少一次字符串转换，高频调用时可省点开销
超时控制不能只靠 context.WithTimeout
Go 的 DNS 查询默认不尊重 context.Context 的 deadline，尤其在系统 resolver（如 musl libc）下，net.DefaultResolver 可能卡住直到系统级超时（常为 5–30 秒）。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：给 net.LookupHost 传一个 500ms 的 context，结果函数仍阻塞 5 秒才返回 context deadline exceeded。
- 必须显式设置
net.DefaultResolver并配置Timeout和PreferGo： net.DefaultResolver = &net.Resolver{PreferGo: true, Dial: (&net.Dialer{Timeout: 2 * time.Second}).DialContext}-
PreferGo: true强制走 Go 原生 resolver，绕过系统 libc，才能真正响应 context deadline - 注意：开启
PreferGo后将忽略 /etc/nsswitch.conf 和某些平台特定行为（如 macOS 的 mDNS）
为什么在 Alpine 容器里 DNS 查询经常失败
Alpine 默认用 musl libc，其 getaddrinfo 实现不支持并发查询，且对 DNS timeout 处理僵硬，配合 Go 的默认 resolver 行为容易触发静默失败或长等待。
典型错误信息：lookup example.com: no such host，但 dig 或 nslookup 能正常工作。
- 最简方案：强制启用 Go 原生 resolver（同上节），避免 musl 路径
- 不要依赖
GODEBUG=netdns=go环境变量——它只影响编译期决策，运行时不可靠 - 检查 /etc/resolv.conf 是否含 search 域；musl 下 search 会触发多次查询，每次失败都算一次超时，叠加后更快耗尽时间
- 如果必须用 musl resolver，确保容器内 /etc/resolv.conf 的 nameserver 是可达的，且不含 IPv6 地址（musl 对 IPv6 DNS 支持较弱）
事情说清了就结束。DNS 查询看着简单，但跨平台、跨 libc、跨 resolver 实现的细节差得远，尤其在容器和 CI 环境里，别信“本地能跑就行”。
