Go HTTP客户端Pod重启后connection refused的根因是连接池复用旧连接、DNS缓存未更新及重试与context取消竞态；需自定义Transport（调小MaxIdleConns、设IdleConnTimeout/KeepAlive）、禁用cgo DNS、手动实现幂等请求重试并协同context超时。
Go HTTP 客户端连接池在 Pod 重启后持续报 connection refused
这是典型节点漂移 + 连接池复用旧连接导致的。K8s 重建 Pod 后，Service 的 ClusterIP 不变，但后端 Endpoint 已更新，而 Go 的 http.Transport 默认会复用空闲连接（MaxIdleConnsPerHost 默认 2），这些连接可能还连着已销毁的老 Pod IP，TCP 层未探测到断连，直到发请求时才暴露 connection refused。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
http.Transport必须显式配置MaxIdleConns和MaxIdleConnsPerHost，避免连接堆积；建议设为较小值（如 20 / 10），尤其在高并发短连接场景 - 启用
ForceAttemptHTTP2: true（Go 1.12+）可提升连接复用稳定性，但需服务端支持 HTTP/2 - 设置
IdleConnTimeout（推荐 30s）和KeepAlive（推荐 30s），让空闲连接主动过期，避免卡在已失效的后端上 - 不要依赖
http.DefaultClient—— 它的 Transport 是全局共享、不可修改的，必须新建http.Client并自定义 Transport
重试逻辑不能只靠 net/http 自动重定向
HTTP 重定向（301/302）是语义重试，不是容错重试。Pod 漂移后常见的失败是 net/http: request canceled (Client.Timeout exceeded while awaiting headers) 或底层 read: connection reset by peer，这类错误不会触发自动重试，必须手动实现。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
github.com/hashicorp/go-retryablehttp替代原生http.Client，它默认重试幂等方法（GET/HEAD/OPTIONS），且可配置RetryMax、RetryWaitMin等 - 若自行封装重试，注意：仅对幂等请求重试；避免在
http.Request.Body已读取或关闭后重复使用（会导致http: invalid Read on closed Body） - 重试间隔建议用指数退避（如 100ms → 200ms → 400ms），并加入 jitter，防止雪崩式重试冲击新 Pod
- 务必设置重试总超时（
context.WithTimeout），否则可能卡死在无限循环里
K8s Service DNS 缓存导致客户端连到已下线的 Endpoint
Go 默认使用 cgo 解析 DNS，会缓存 ClusterIP 对应的后端 Pod IP（即 Endpoints），而 K8s Endpoints 更新有延迟（默认 endpointslice 同步间隔约 10s），加上 Go 的 net.Resolver 无 TTL 控制，可能导致客户端持续往已销毁的 Pod 发请求。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 强制 Go 使用纯 Go DNS 解析器：
GODEBUG=netdns=go启动参数，避免 cgo 缓存干扰 - 为
http.Transport配置Resolver，自定义带 TTL 的 DNS 缓存（如用github.com/miekg/dns实现 5s TTL 查询） - 更简单有效的方式：禁用 DNS 缓存，每次请求前重新解析 —— 在
RoundTrip前调用net.DefaultResolver.LookupHost获取最新 IP，并构造直连http://ip:port请求（绕过 Service DNS） - 注意：若用 Headless Service（
clusterIP: None），客户端应直接解析 DNS SRV 记录，此时需确保应用能处理 DNS 变更并刷新连接池
连接池重试与 context 取消的竞态问题
当 HTTP 请求被 context.Context 取消时，Go 的 http.Transport 会立即关闭底层连接，但如果此时重试逻辑正在新建连接，就可能触发 use of closed network connection 或 http: server closed idle connection 类错误。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 重试逻辑必须检查
ctx.Err() != nil再决定是否发起下一次请求，不能只看 error 类型 - 不要在重试循环里复用同一个
http.Request—— 每次重试都应新建http.NewRequestWithContext(ctx, ...)，确保上下文传播正确 - 如果用了
retryablehttp，务必传入带 timeout/cancel 的 context，并设置RetryMax: 3等硬限制，防止 cancel 后仍尝试建连 - 观察日志中是否高频出现
context canceled伴随http: server closed idle connection—— 这往往是重试未及时响应 cancel 的信号
最易被忽略的是：连接池的 IdleConnTimeout 和业务层 context.Timeout 必须协同，前者不能远大于后者，否则连接会“活着”但业务早已放弃，白白占资源又不参与重试决策。
