Go 的 net.LookupIP 失败时，错误类型不只有 net.DNSError
Go 的 DNS 解析函数（如 net.LookupIP、net.LookupHost）在失败时可能返回多种错误：除了常见的 net.DNSError，还可能是 context.DeadlineExceeded、net.OpError（底层连接超时或拒绝），甚至 nil 地址切片 + nil 错误（极少见，但某些 stub resolver 或 mock 环境下会出现）。直接用 errors.Is(err, &net.DNSError{}) 判断会漏掉超时类错误。
- 真正要捕获“DNS 层面不可达”，得同时检查：
err是否为*net.DNSError且.IsNotFound或.IsTemporary为true - 若使用了带
context.Context的变体（如net.Resolver.LookupIPAddr），必须额外判断context.DeadlineExceeded和context.Canceled -
net.DNSError的Timeout()方法返回false即使是 DNS 超时——它只反映底层系统调用是否被 OS 标记为 timeout，不能依赖
自定义 net.Resolver 是控制 DNS 行为的唯一可靠方式
默认解析器走系统配置（/etc/resolv.conf 或 Windows 注册表），无法设置超时、重试、备用服务器。想做容错，必须显式构造 net.Resolver 实例，并传入自定义 net.Dialer。
- 设置 DNS 超时：用
&net.Resolver{Dial: func(ctx context.Context, network, addr string) (net.Conn, error) { ... }}，在dialer.DialContext中设Timeout和KeepAlive - 指定 DNS 服务器：把
addr改成"8.8.8.8:53"或"1.1.1.1:53"，不要依赖系统默认 - 避免 UDP 截断导致失败：对大响应，Go 默认会自动 fallback 到 TCP，但前提是底层
net.Conn支持；确保你的Dial函数对"tcp"和"udp"都有处理
net.DefaultResolver 在容器或 CI 环境中大概率不可靠
很多 Alpine 镜像、Kubernetes Pod 或 GitHub Actions 运行器里，/etc/resolv.conf 可能为空、指向 127.0.0.11（dockerd 内置 DNS），或被精简掉 search 域。这时 net.DefaultResolver 会静默失败或返回错误结果，而不是抛出明显异常。
- 上线前务必验证：在目标环境跑一段最小代码，调用
net.DefaultResolver.LookupHost(context.Background(), "google.com")并打印错误 - CI 中建议强制覆盖：用
NET_RESOLVER_CONFIG环境变量（需自己解析）或直接 new 一个 resolver，硬编码可信 DNS - 注意 glibc vs musl 差异：Alpine（musl）下
net.DefaultResolver不读resolv.conf的options timeout:，而 glibc 会——别指望配置文件生效
并发解析多个域名时，别用 sync.WaitGroup 简单等结果
如果一批域名需要并行查 DNS，常见写法是起 goroutine + WaitGroup，但这样无法优雅中断失败请求，也无法统一控制超时。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：用
errgroup.Group+ 共享context.Context，任意一个解析失败或超时，其余自动取消 - 别对每个域名单独设不同超时——DNS 服务器响应时间波动大，应统一用一个 context 控制整体 deadline
- 结果聚合时注意：
net.LookupIP返回的[]net.IP顺序不保证 IPv4/IPv6 优先，需要按业务需要过滤或排序，比如只取第一个net.IPv4
LookupIP 调用在不同机器上表现迥异。最稳妥的做法，是彻底绕过 net.DefaultResolver，自己管 dial、timeout、server、fallback。 
