Go 的 net.DefaultResolver 不重试，网络抖动时直接返回底层错误；应显式构造带指数退避重试的 *net.Resolver，仅对 IsTemporary=true 错误重试，gRPC 需用拦截器而非 retryablehttp，HTTP 客户端须分层设超时并配合熔断与可观测性闭环。
Go 的 net.DefaultResolver 不重试，抖动时直接失败
Go 标准库的 net.DefaultResolver 在遇到 UDP 超时（i/o timeout）、连接拒绝（read: connection refused）或路由不可达（no route to host）时，**不会自动重试**——它原样返回错误。网络抖动常表现为这些临时性底层错误，而非明确的 DNS name does not exist。这意味着你看到的往往是 context.DeadlineExceeded 或 syscall 错误，而不是可预期的解析失败。
实操建议：
- 永远不要依赖
net.DefaultResolver应对抖动；必须显式构造带重试逻辑的*net.Resolver - 单次查询超时设为 ≤ 2s（用
WithContext控制），避免阻塞整个 HTTP 请求链 - 重试次数控制在 2–3 次，间隔用指数退避 + 抖动，例如
100ms → 300ms → 800ms - 区分可重试与不可重试错误：
err.(*net.DNSError).IsTemporary == true才考虑重试；IsNotFound == true或IsTimeout == false的错误直接放弃
gRPC 调用不能套用 retryablehttp，协议栈不兼容
retryablehttp 是 HTTP/1.1 工具，而 gRPC 基于 HTTP/2，二者在状态码语义、流控机制、元数据透传和错误类型上完全不兼容。硬套会导致重试逻辑失效、panic 或 trace ID 丢失。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 对
codes.DeadlineExceeded也发起重试，但该错误已是超时结果，再重试只会加剧雪崩 - 重试后
metadata.MD（如鉴权 token、trace ID）丢失，链路追踪断裂 - 遇到
stream.SendMsg直接 panic：库根本不支持流式重试
正确做法是用 gRPC 拦截器 + backoff 库：
- 只重试临时性错误：
codes.Unavailable、codes.ResourceExhausted、codes.Aborted - 跳过语义错误：
codes.InvalidArgument、codes.NotFound、codes.AlreadyExists - 用
github.com/cenkalti/backoff/v4配置MaxElapsedTime（总耗时上限），而非仅靠重试次数 - 每次重试前调用
bo.NextBackOff()获取新延迟，且必须新建context.WithTimeout，否则原 deadline 会传染
HTTP 客户端要分层设超时，别只靠 client.Timeout
http.Client.Timeout 只控制“整个请求生命周期”，无法覆盖连接建立、TLS 握手、响应头读取等中间环节。网络抖动常卡在某一个子阶段（比如 DNS 解析完但 TCP 连不上），此时 client.Timeout 还没触发，连接池却已耗尽。
实操建议：
- 必须配置
http.Transport的细分超时：DialContext.Timeout（TCP 连接）、TLSHandshakeTimeout、ResponseHeaderTimeout - 连接池参数要匹配业务：高并发场景下
MaxIdleConnsPerHost至少设为 100，避免因复用不足频繁建连 - 所有出站请求必须用
context.WithTimeout包裹，且 timeout 值应小于client.Timeout，形成嵌套防御 - 禁用默认
http.DefaultClient，它Timeout = 0（无限制），生产环境极易引发雪崩
抖动不是单点问题，得配合熔断与可观测性闭环
重试只是应对抖动的第一步。如果下游持续不可用，重试反而放大压力。真正稳定的系统必须把重试、熔断、降级、监控串成闭环。
关键落地点：
- 熔断器（如
sony/gobreaker）要基于错误率+时间窗口统计，比如连续 5 次失败且错误率 > 50% 触发熔断，等待 30 秒后半开试探 - 熔断期间必须有轻量降级逻辑：返回缓存、静态兜底值或空响应，避免降级本身又引入新依赖
- 所有重试次数、熔断状态、DNS 解析耗时必须暴露为 Prometheus 指标（如
http_retry_count_total、circuit_breaker_state） - 日志中必须带 trace ID 和重试标记（如
retry_attempt=2），否则抖动问题根本无法关联定位
最容易被忽略的是：重试和熔断的阈值必须随环境动态调整。开发环境容忍度高，生产环境必须更激进——比如超时从 5s 缩到 1s，熔断错误率从 50% 降到 30%。
