go 默认dns解析高并发下变慢，因defaultresolver不缓存、不复用连接且依赖系统解析；解决方案是用miekg/dns搭本地缓存dns服务，并显式配置net.resolver指向它。
Go 默认 DNS 解析为什么在高并发下变慢
Go 的 net.DefaultResolver 默认使用系统 /etc/resolv.conf，每次解析都走完整 DNS 流程（含超时重试、TCP fallback），且不共享连接、不缓存成功结果。高并发场景下，大量 goroutine 同时调用 net.LookupIP 或 http.Client 发起请求，会瞬间打满 DNS 服务器或本地 stub resolver，出现 lookup xxx: no such host 或延迟飙升到几百毫秒。
- Go 1.19+ 虽引入了部分内部缓存（如对
localhost等固定名），但对动态域名仍无有效 TTL 缓存 -
net.Resolver的PreferGo字段设为true会启用 Go 自研解析器，但它默认仍不缓存 A/AAAA 记录 - 系统级 DNS 缓存（如 systemd-resolved）不可靠：Go 不读取其 socket，且容器中常被绕过
用 github.com/miekg/dns 搭建轻量级本地 DNS 缓存服务
自己写一个极简 DNS 代理比改 Go 运行时更可控。用 miekg/dns 库监听 127.0.0.1:5353，上游转发到公共 DNS（如 1.1.1.1），并基于响应中的 Answer TTL 做内存缓存。它不依赖 cgo，适合容器部署。
- 缓存键必须包含
Qname + Qtype（比如api.example.com的A和AAAA要分开存） - TTL 到期后不能直接丢弃，要设为「stale」状态，在后台异步刷新，避免缓存击穿
- 务必限制最大缓存条目数（如
10000）和单条 TTL 上限（如300s），防止内存无限增长 - 示例关键逻辑：
cache.Set(key, answer, int(ttl)) // ttl 来自 DNS response 中的 RR.TTL
让 Go 应用强制走本地缓存 DNS
不能只靠改 /etc/resolv.conf —— 容器里它可能被覆盖，且 Go 的 net.Resolver 在 PreferGo=false 时仍会绕过本地 UDP 监听。必须显式配置 Resolver。
- 全局替换：
net.DefaultResolver = &net.Resolver{<br> PreferGo: true,<br> Dial: func(ctx context.Context, network, addr string) (net.Conn, error) {<br> return net.DialContext(ctx, "udp", "127.0.0.1:5353")<br> },<br>} - HTTP 客户端也要同步配置：
http.DefaultClient.Transport.(*http.Transport).DialContext通常不用动，因为net.Resolver已接管；但若用了自定义http.Transport，需确保其Resolver字段指向同一实例 - 注意：Kubernetes Pod 中若启用了
hostNetwork: true，127.0.0.1会指向宿主机，此时应改用localhost或明确 Service IP
缓存失效与滚动更新时的坑
DNS 缓存最麻烦的不是性能，而是“该更新时不更新”或“不该更新时乱更新”。比如服务扩缩容后 VIP 变了，但旧 IP 还在缓存里，导致部分请求失败。
立即学习“go语言免费学习笔记（深入）”；
- 不要信任 DNS 响应里的 TTL：有些 CDN 或负载均衡器故意返回
300秒，实际后端变更频繁，建议硬编码最大缓存时间（如60s） - 当应用收到
SIGHUP或配置热重载信号时，主动清空缓存（或标记全 stale），而不是等自然过期 - 如果上游 DNS 返回
NOERROR但Answer为空（常见于灰度切流阶段），缓存层必须透传这个空响应，并设置较短 TTL（如5s），否则会把“暂时不可用”缓存太久 - 健康检查不能只 ping
127.0.0.1:5353，要发真实A查询并验证响应是否含有效记录
真正难的不是搭个缓存，是让缓存行为和业务发布节奏对齐——比如蓝绿发布窗口期内，DNS 缓存的刷新策略得跟着 Deployment 的 readiness probe 状态走。
