Go http 客户端连接池怎么调优？

http.defaultclient高并发卡住因默认连接池保守：maxidleconns和maxidleconnsperhost均为100、idleconntimeout为30秒，导致连接复用率低、频繁重建；需调大两参数并缩短超时时间，配合及时关闭response.body及合理监控。

为什么 http.DefaultClient 在高并发下会卡住？

因为它的默认连接池太“保守”：MaxIdleConns 和 MaxIdleConnsPerHost 都是 100，IdleConnTimeout 是 30 秒。当并发请求突增，大量连接在复用前就超时关闭，新请求只能重建连接，触发 DNS 查询、TLS 握手，延迟飙升。

典型现象是：QPS 上不去、net/http: request canceled (Client.Timeout exceeded while awaiting headers) 频发、go tool trace 显示大量 goroutine 堵在 transport.roundTrip。

• 优先调大 MaxIdleConns（全局空闲连接上限），建议设为 500–2000，取决于后端能承受的连接数
• MaxIdleConnsPerHost 必须同步调大，否则单 host 连接数仍被卡死；设为 MaxIdleConns / 后端域名数量 的 2–3 倍更稳妥
• IdleConnTimeout 建议缩到 30–90 秒——太长易积压失效连接，太短又频繁重建；若后端有连接空闲淘汰（如 Nginx 的 keepalive_timeout），这里必须小于它

怎么给特定域名单独配连接池？

用 http.Transport 的 ProxyConnectHeader 或自定义 DialContext 并不能实现 per-host 池，真正有效的是靠 Transport.RegisterProtocol 或更直接的方式：为不同 host 创建独立 http.Client 实例，并各自配置 Transport。

聪豹Wiseal

聪豹Wiseal是一个专业的历史时间线收集整理工具

下载

但更常用且轻量的做法是利用 Transport 内置的 host 粒度控制：

• 设置 MaxIdleConnsPerHost 足够大（比如 500），再配合 IdleConnTimeout 和 TLSHandshakeTimeout
• 若某 host（如支付回调地址）稳定性差或需隔离故障，可单独构造一个 http.Client，传入定制 Transport，并禁用其与其他 host 共享连接池
• 注意：不要手动修改 Transport 的 idleConn map，那是未导出字段，强行反射操作极易引发 panic 或数据竞争

http.Transport 的 Response.Body 不 close 会导致连接泄漏吗？

会，而且非常隐蔽。只要没调 resp.Body.Close()，底层连接就不会归还给 idle pool，持续占用直到 IdleConnTimeout 到期——这期间该连接无法复用，等于“假死”。

• 即使 resp.StatusCode 是 4xx/5xx，也必须 close Body；Go 1.19+ 加了 resp.Uncompressed 提示，但不改变 close 责任
• 推荐写法：defer resp.Body.Close() 放在 if err != nil 检查之后，避免 panic 时跳过
• 用 io.Copy(io.Discard, resp.Body) 替代 io.ReadAll 处理大响应体，防止 OOM 同时确保流式消费完

HTTP/2 对连接池有影响吗？

有，而且是根本性影响：HTTP/2 默认复用单连接传输多请求（multiplexing），所以 MaxIdleConnsPerHost 的意义弱化，重点转向 MaxConnsPerHost（Go 1.19+ 引入）和流控参数。

• HTTP/2 下，MaxIdleConnsPerHost 控制的是“空闲 HTTP/2 连接数”，不是“空闲流数”；实际并发流由服务端 SETTINGS_MAX_CONCURRENT_STREAMS 决定
• 若遇到 http2: server sent GOAWAY and closed the connection; error: code=ENHANCE_YOUR_CALM，大概率是客户端发起太多 stream，应检查是否漏关 body 或存在循环请求
• 对内网调用，可考虑显式禁用 HTTP/2：Transport.ForceAttemptHTTP2 = false，避免某些旧版中间件兼容问题