go 的 http.client 默认自带连接池，无需手动实现；关键在合理配置 maxidleconnsperhost（默认仅2，易致频繁建连）、idleconntimeout（推荐30–90s）等 transport 参数，并确保调用 resp.body.close() 以归还连接。
go 的 http.client 默认就有连接池，别自己手写
很多人一搜“go 连接池”，立马去实现 sync.pool 或用 chan 管理 net.conn，纯属白忙——http.client 底层的 http.transport 早把连接复用、空闲池、keep-alive、tls 复用全包了。只要你不显式设置 transport 为 nil，也不手动关掉 disablekeepalives，连接池就在跑。
典型误操作包括：
- 每次请求都
new(http.Client{})，导致 Transport 实例泛滥、连接无法复用 - 全局替换
http.DefaultTransport，结果其他包（比如go.opentelemetry.io或cloud.google.com/go）的 HTTP 调用也跟着被改，引发超时或连接耗尽 - 以为要“手动维护 conn 列表”，结果写了半天发现根本没走 keep-alive，全是短连接
MaxIdleConnsPerHost 是最常配错的参数
这个值控制「每个目标 host 能缓存多少个空闲连接」，不是并发上限，也不是活跃连接数上限。它只管“请求结束、连接还健康、且想留着下次用”的那部分连接。
常见错误现象是：调同一个下游服务（比如 https://api.pay.example.com），QPS 上去后大量 net/http: request canceled (Client.Timeout exceeded while awaiting headers)，或者 TIME_WAIT 连接暴涨——往往就是它设太小（默认仅 2），导致连接刚用完就被关，下次还得重连。
调优建议：
- 对固定 host 的高频调用（如支付网关），设为预期并发请求数的
1/3～1/2；例如稳定压测 60 QPS，可设25～30 - 如果调用目标分散（比如同时打 50 个不同域名），
MaxIdleConns（全局总数）得同步放大，否则池子被某几个 host 占满，别的 host 就拿不到空闲连接 - 设太大（比如 >100）不光浪费内存，还会让失效连接滞留更久，尤其当下游服务重启或 LB 变更 IP 后，旧连接可能卡在池里继续失败
超时配置必须分层，不能只靠 Client.Timeout
http.Client.Timeout 是总超时，覆盖建连、重定向、读响应体全过程；但它不控制连接池内部行为。真正影响复用效率的是 http.Transport 的几个关键超时：
-
DialTimeout：TCP 建连最大耗时，建议3～5s；设太长会让失败连接卡住整个池 -
TLSHandshakeTimeout：HTTPS 场景下必须单独设，和DialTimeout分开，同样建议 ≤5s -
IdleConnTimeout：空闲连接在池里最多躺多久，建议30～90s；太短（如5s）会导致刚缓存就过期，复用率归零；太长（如5m）则可能保留已断开的连接 -
ResponseHeaderTimeout：从发完请求到收到响应头的时间，防下游卡死；建议略大于下游 P95 响应头时间
漏配其中任何一个，都可能让连接池“看起来在工作”，实则大量连接反复新建、频繁握手、或卡在 idle 状态不释放。
生产环境推荐的最小安全配置
这不是万能模板，但能避开 80% 的连接池相关线上问题：
tr := &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 25,
MaxConnsPerHost: 50,
IdleConnTimeout: 90 * time.Second,
DialTimeout: 5 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
ResponseHeaderTimeout: 10 * time.Second,
ForceAttemptHTTP2: true,
}
client := &http.Client{
Transport: tr,
Timeout: 30 * time.Second,
}
注意：MaxConnsPerHost 是硬限，防止对单个下游打爆；ForceAttemptHTTP2 开启后，即使服务端支持 HTTP/2，也能避免降级到 HTTP/1.1 导致连接复用效率下降；所有超时值都要结合你实际链路的延迟分布来微调，不能照抄。
最容易被忽略的一点：连接池效果高度依赖下游是否真正返回 Connection: keep-alive 和正确关闭连接。如果对方服务是 Nginx 但配置了 keepalive_timeout 0，或者用了不兼容的代理层，再好的客户端配置也白搭。
