Go中DNS自动化管理需手动组合net.Resolver、DialContext、缓存与健康探测，核心是显式控制解析链路，缺PreferGo、DialContext或LookupIP任一环即退化为不可控系统解析。
net.Resolver 不是“域名管理”模块，它只负责解析——所谓自动化，本质是把解析控制权从系统手里抢过来，再套上缓存、健康探测、fallback 逻辑。
为什么直接改 /etc/resolv.conf 或设 GODEBUG=netdns=go 不行
这两招只能影响 Go 运行时默认 resolver 的行为，但：
- http.Client 在 TLS 握手阶段仍会绕过它，走 libc 的 getaddrinfo；
- Kubernetes Headless Service 场景下，LookupHost 会去重并随机返回一个 IP，而你通常需要全部；
- 没法指定上游 DNS 服务器（比如强制走 1.1.1.1），也没法加超时或重试。
net.Resolver 必须显式构造并设 PreferGo: true
这是开关，不是建议。不设它，你的 Dial 函数根本不会被调用。
常见错误写法：
- 直接 new 一个 net.Resolver{} 不设 PreferGo；
- 以为设了 GODEBUG 就够了；
- 把 Dial 写成 return net.Dial("udp", "1.1.1.1:53")，没包进 context.Context，导致无法中断。
-
Dial参数里network只能是"udp"或"tcp"，addr是纯地址字符串（如"1.1.1.1:53"），不能带协议前缀 - 必须用
net.Dialer{Timeout: ...}.DialContext(ctx, network, addr)，硬写net.Dial会卡死协程 - 若只查 IPv4，
LookupIP第二个参数传"ip4"，否则可能因 AAAA 查询失败连带让整个解析失败
http.Client 要手动接入自定义 resolver
http.Client 完全不认 net.Resolver 实例。它只看 http.Transport.DialContext。
错误做法：
- 只改 Transport.Dial（旧接口），它不参与 TLS 建立；
- 忘记在 DialContext 里调 resolver.LookupIP，结果还是走系统 DNS；
- 对 Headless Service 用 LookupHost，拿不到全部 Pod IP。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 务必用
resolver.LookupIP(ctx, "ip", host)，尤其对my-svc.default.svc.cluster.local这类 - 如果后端启用了 SNI（几乎所有 HTTPS 服务），记得把原始
host赋给TLSConfig.ServerName，否则证书校验失败 - HTTP 连接复用时，
Transport默认缓存 DNS 结果（TTL=0），需配合自定义 resolver 自己做缓存，或设Transport.IdleConnTimeout避免 stale 连接
Headless Service 场景下必须用 LookupIP 而非 LookupHost
Kubernetes Headless Service 不生成聚合 A 记录，而是为每个 Pod 返回独立的 A/AAAA 记录。LookupHost 内部做了去重+随机选一个，LookupIP 才返回完整列表。
典型现象：
- 服务只连到一个 Pod，负载不均；
- 日志里反复报 no such host，其实是某次解析返回空列表（因某个 Pod 临时不可达）。
- 调用时明确指定
"ip"或"ip4"，避免协议协商失败 - 返回的
[]net.IP需你自己做健康探测和轮询，Go 不提供内置负载均衡 - 别依赖
net.Resolver自带缓存：它的 TTL 解析逻辑在PreferGo: true下才生效，且默认不缓存
真正难的不是写几行 resolver 代码，而是把 DNS 解析从“系统自动完成”的黑盒，变成可观察、可干预、可 fallback 的显式链路——一旦漏掉 PreferGo、DialContext、LookupIP 三者中任一环，就退回到不可控状态。
