Go 语言中 net/http 长连接复用时的 MaxIdleConns 调优

MaxIdleConns是全局空闲连接总数上限，MaxIdleConnsPerHost是单host最大空闲连接数，后者不能超过前者；若只调大后者而忽略前者，多host会争抢导致部分域名无法复用连接，合理协同配置才能提升复用效率。

说到Go的net/http连接池调优，有个容易踩坑的地方：很多人以为把几个连接参数往大调就万事大吉了，结果压测一上，超时、失败、TIME_WAIT满天飞。其实，参数之间是联动的，单独调某一个往往顾此失彼。 **关键点在于：MaxIdleConns不是并发上限，设太大反而会拖慢连接复用效率，必须和MaxIdleConnsPerHost、目标服务分布协同调整。**  ### MaxIdleConns 和 MaxIdleConnsPerHost 的关系容易搞反 这两个参数不是独立生效的：MaxIdleConns 是全局空闲连接总数上限，MaxIdleConnsPerHost 是单个 host（比如 `api.example.com:443`）最多能缓存的空闲连接数。但后者不能超过前者——如果 `MaxIdleConns` 设为 100，`MaxIdleConnsPerHost` 却设成 200，实际生效的仍是 100。 常见错误是只调大 `MaxIdleConnsPerHost`，却忘了同步放大 `MaxIdleConns`，结果多个 host 抢同一个池子，某些域名始终拿不到空闲连接。 - 只调一个后端服务？`MaxIdleConns` 可设为 0（不限制），重点调 `MaxIdleConnsPerHost` - 同时调 20+ 个不同域名？`MaxIdleConns` 至少设为 `MaxIdleConnsPerHost × 3`，留出余量 - 默认值 100 在多数微服务场景下偏小，压测时容易看到大量 `net/http: request canceled (Client.Timeout exceeded while awaiting headers)` ### 设太高会导致失效连接滞留、内存浪费甚至服务端拒绝 连接池不是越大越好。`MaxIdleConns` 过大会让已断开或服务端已回收的连接在客户端池里“装死”更久，尤其当下游 LB 切换 IP 或服务重启后，这些连接仍被复用，直接返回 `i/o timeout` 或空响应。 - 单机 QPS MaxIdleConns = 200 足够 - QPS 200+ 且目标分散？建议 `MaxIdleConns = 500`，再配合监控看 `http.Transport.IdleConnMetrics` 中的 rejected 连接数 - 设到 1000+ 且没配套健康检查？大概率会观察到 TIME_WAIT 暴涨 + 随机超时，不是连接没复用，而是复用了坏连接 ### 不共享 Client 实例时，MaxIdleConns 完全无效 `MaxIdleConns` 是 `http.Transport` 的字段，而 Transport 必须被多个请求共用才能体现池的效果。如果每次请求都 `&http.Client{Transport: &http.Transport{...}}`，等于每个 Client 各自建了个迷你池，参数再大也没意义。 - 必须将 `*http.Client` 作为包级变量或依赖注入单例使用 - 禁止在 HTTP handler 里 new Client，也禁止用 `http.DefaultClient`（它的 Transport 无法修改） - 多个业务逻辑需要不同超时？新建 `http.Transport`，再传给新 `http.Client`；别复用 Transport 却改 Client.Timeout 真正难调的不是数值本身，而是确认连接到底有没有被复用——用 `curl -v` 看响应头有没有 `Connection: keep-alive`，再用 `netstat -an | grep :443 | grep ESTABLISHED | wc -l` 对比压测前后数量变化，比光看参数靠谱得多。