DNS解析拖垮微服务调用，因Go默认net.DefaultResolver依赖不可靠的/etc/resolv.conf和系统库，且无超时机制；须用PreferGo:true的自定义Resolver绑定带Timeout的Dialer并硬编码可信DNS地址，HTTP/gRPC需分别配置，且所有调用必须透传context.WithTimeout。
为什么 DNS 解析会拖垮微服务调用
Go 默认用 net.DefaultResolver，它依赖系统 /etc/resolv.conf 和底层 libc/musl 实现，但在容器、K8s 或 CI 环境中常出现：no DNS servers found（*net.DNSConfigError），或静默返回过期 IP；更隐蔽的是，DNS 查询本身没设超时，一次卡住就阻塞整个 HTTP/gRPC 请求，而 http.Client.Timeout 根本不覆盖这一阶段。
必须用自定义 net.Resolver 替代默认解析器
不能只改 http.Transport，得从源头接管 DNS 行为。关键点：
-
PreferGo: true强制走 Go 原生解析器，绕过 cgo 和系统库差异（尤其 Alpine 镜像） -
Dial字段必须传入带Timeout的net.Dialer，否则 UDP/TCP 查询都可能无限等待 - 硬编码可信 DNS 地址（如
"8.8.8.8:53"），别信/etc/resolv.conf—— 它在 Pod 里常是127.0.0.11（dockerd 内置 DNS），响应慢且不可控 - 对
udp和tcp网络都做处理，避免大响应被截断后 fallback 失败
示例：
resolver := &net.Resolver{
PreferGo: true,
Dial: func(ctx context.Context, network, addr string) (net.Conn, error) {
d := net.Dialer{Timeout: 1 * time.Second, KeepAlive: 30 * time.Second}
return d.DialContext(ctx, network, "8.8.8.8:53")
},
}
gRPC 和 HTTP 都要绑定这个 resolver
HTTP 客户端需注入 resolver 到 http.Transport；gRPC 则通过 grpc.WithResolvers 注册。两者不互通，必须分别配置：
- HTTP：构造
http.Transport时，把resolver传给Proxy或封装进自定义DialContext（实际需包装net.Dialer的DialContext方法） - gRPC：
grpc.Dial("user-service.internal", grpc.WithResolvers(resolver))—— 注意不是WithResolver（单数），而是复数形式 - 所有下游调用（包括重试）都复用同一 resolver 实例，避免并发查 DNS 时各自超时失控
别忽略 context 在 DNS 阶段的透传
DNS 查询本身支持 context.Context，但只有显式调用 resolver.LookupHost(ctx, host) 才生效。常见错误：
- 直接调用
net.LookupHost(host)→ 走net.DefaultResolver，无视你配的自定义 resolver - 在
http.Client.Do()前没把请求上下文传进去 → 即使 resolver 设了 1s 超时，HTTP 层仍可能因其他环节卡住 - 用
errgroup.Group并发查多个域名时，没共用同一个ctx→ 某个域名慢，其余无法自动取消
真正安全的写法是：所有网络操作入口（HTTP 请求构造、gRPC 方法调用、手动 DNS 查询）都接收并透传上游 ctx，且该 ctx 必须来自 context.WithTimeout，不是 context.Background()。
最易被忽略的一点：DNS 解析失败时，errors.Is(err, &net.DNSError{}) 不够，还得检查 context.DeadlineExceeded 和 context.Canceled —— 因为超时是 context 层面的，不是 DNS 库自己抛的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
