你可能见过这样的情况：Go 服务刚上线时响应很快，流量一上来就开始变慢，严重时还会报出 too many open files。这类问题很多时候并不在业务代码本身，而是出在 net/http 的连接复用和超时策略上。下面就按“为什么会慢、该调哪些参数、线上应该怎么配、有哪些坑要避开”的顺序，拆开说明高并发下 HTTP 连接池的关键点。
为什么高并发下必须关注 HTTP 连接池
HTTP 请求的底层仍然依赖 TCP 连接，而建立 TCP 连接本身就是一笔不小的开销，需要经过三次握手。如果每次请求都重新建连，请求量一大，连接建立和销毁就会持续吃掉系统资源。
Go 标准库里的 net/http 其实已经内置了连接池能力。只要使用 http.Client 发请求，底层就会尽可能复用 TCP 连接，减少重复建连成本。
问题在于，默认配置更偏向通用场景，而不是高并发服务场景。最典型的例子就是 MaxIdleConnsPerHost 默认值只有 2，这对并发量较高的服务几乎肯定不够用。结果就是连接复用不充分，请求排队增多，系统还可能因为连接数失控而触发文件描述符耗尽。
连接池最值得先看的 4 个参数
MaxIdleConnsPerHost：每个主机保留多少空闲连接
这是最影响性能的参数之一，用来控制单个目标主机可保留的最大空闲连接数。默认值只有 2，在高并发环境下通常过小。
transport := &http.Transport{
MaxIdleConnsPerHost: 20, // 建议设置为并发数的1/3到1/2
}实践里，这个值往往比想象中更敏感。有项目只是把它从 2 提高到 50，QPS 就提升了整整 3 倍。
MaxIdleConns：整个客户端最多保留多少空闲连接
这个参数控制的是全局维度的空闲连接总数，不区分主机。如果服务会同时访问多个下游，它就不能只看单个主机配置，还要给全局池子留出足够空间。
transport := &http.Transport{
MaxIdleConns: 100, // 通常设置为MaxIdleConnsPerHost * 预期服务数量
}如果你配置了较高的 MaxIdleConnsPerHost，但全局 MaxIdleConns 太小，最终也会限制连接复用效果。
IdleConnTimeout：空闲连接保留多久
连接放进池子里并不代表要一直留着，IdleConnTimeout 决定了空闲连接在连接池中的存活时间。
transport := &http.Transport{
IdleConnTimeout: 90 * time.Second,
}这个值太短，会让连接来不及复用就被回收；太长，又会额外占用资源。像 90 * time.Second 这样的配置，通常是一个比较稳妥的起点。
MaxConnsPerHost：给单个主机设连接上限
这个参数限制的是对单个主机的总连接数，包含活跃连接和空闲连接。它的意义不是提升复用，而是防止连接数在压力下无限扩张。
transport := &http.Transport{
MaxConnsPerHost: 50, // 设置为峰值并发数
}对于高并发调用下游服务的场景，这个上限非常重要。没有它，连接数在异常抖动时更容易冲高，进而拖垮进程或下游。
生产环境可直接参考的客户端配置
如果服务需要长期稳定地访问下游接口，通常应该明确创建一个自定义客户端，把连接池和超时参数一起配好，而不是依赖默认值。
func createProductionClient() *http.Client {
transport := &http.Transport{
// 连接池配置
MaxIdleConns: 100,
MaxIdleConnsPerHost: 25, // 并发请求数的1/3到1/2
MaxConnsPerHost: 50, // 峰值并发数
IdleConnTimeout: 90 * time.Second,
// 超时配置
DialContext: (&net.Dialer{
Timeout: 5 * time.Second, // 建立TCP连接超时
KeepAlive: 30 * time.Second, // TCP保活周期
}).DialContext,
TLSHandshakeTimeout: 5 * time.Second, // TLS握手超时
ResponseHeaderTimeout: 10 * time.Second, // 读取响应头超时
}
return &http.Client{
Transport: transport,
Timeout: 30 * time.Second, // 整体请求超时
}
}这类配置有几个核心思路：
- 连接池参数要围绕实际并发来定，而不是照搬默认值。
- 连接建立、TLS 握手、响应头读取和整体请求，都应该分别设置超时。
http.Client应该在应用内复用，而不是每次请求临时创建。
如果你的服务访问的下游比较固定，这样的客户端通常可以作为一个稳定基线，再根据压测结果微调。
别只设一个 Timeout：更稳妥的是分层超时
很多服务的问题不只是连接池小，而是超时控制太粗。只设置一个总超时，往往不足以区分问题出在哪个阶段；完全不设超时，则更危险，请求可能长时间挂起，逐步耗尽工作协程和连接资源。
更实用的做法是分层设置超时：
client := &http.Client{
Timeout: 5 * time.Second, // 整体超时时间
Transport: &http.Transport{
ResponseHeaderTimeout: 2 * time.Second, // 读取响应头超时
DialContext: (&net.Dialer{
Timeout: 1 * time.Second, // 建立TCP连接超时
}).DialContext,
},
}这样的好处在于：
DialContext能快速拦住建连慢的问题。TLSHandshakeTimeout适合识别 TLS 握手阶段的异常。ResponseHeaderTimeout可以限制服务端迟迟不回响应头的情况。http.Client.Timeout则作为整次请求的总兜底。
某支付系统在加入分级超时控制后，接口成功率从 99.5% 提升到了 99.9%。这说明超时并不只是“失败更快”，本质上也是在保护服务整体可用性。
线上最常见的 3 个坑
1. 响应体没处理完，连接无法回池
最常见的问题之一，是请求返回后没有正确关闭响应体。这样连接就无法复用，长期积累后非常容易把文件描述符耗光。
处理方式很明确：读取剩余数据，再关闭 resp.Body。
resp, err := client.Get(url)
if err != nil {
return err
}
defer func() {
if resp.Body != nil {
io.Copy(io.Discard, resp.Body) // 读取剩余数据
resp.Body.Close() // 关闭Body
}
}()这里的关键不是只写一个 Close()，而是尽量把剩余内容读完，让连接满足复用条件，顺利归还连接池。
2. 在生产环境直接用 http.DefaultClient
http.DefaultClient 用起来很方便，但它没有超时设置，连接池参数也相对保守。拿它直接跑生产流量，通常不是一个好选择。
// 不要使用默认客户端进行生产请求
// client := http.DefaultClient // 错误方式
// 应该创建自定义客户端
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
MaxIdleConnsPerHost: 20,
},
}如果服务是核心链路上的调用方，自定义客户端几乎应该视为基本要求，而不是优化项。
3. 所有调用场景共用一套参数
不同请求类型的特征并不一样。内部微服务调用、第三方 API 接入、高并发热点接口，对连接数和超时的要求都可能不同。全部共用同一套配置，通常很难跑到最优。
| 场景 | 建议配置 |
|---|---|
| 简单API调用 | http.Get()或默认客户端 |
| 微服务内部通信 | 自定义连接池和超时 |
| 第三方API集成 | 自定义超时和重试机制 |
| 高并发场景 | 精确控制连接数和超时 |
简单说，客户端配置应该跟着调用特征走，而不是图省事全部统一。
实战配置建议：从能用到跑稳
把上面的参数和常见问题放到一起看，线上实践里最值得坚持的其实就四条：
- 先调连接池，再谈吞吐。 重点关注
MaxIdleConnsPerHost、MaxIdleConns和MaxConnsPerHost，并通过压测验证。像MaxIdleConnsPerHost设为预期并发数的1/3到1/2，往往是比较实用的起点。 - 始终读取并关闭响应体。 这是连接能否复用的前提。少了这一步，连接池配置得再好也会失效。
- 复用同一个或少量客户端实例。 绝对不要为每个请求单独创建新的
http.Client，否则连接池几乎没有发挥空间。 - 把超时拆到不同阶段。 除了总超时，还要按建连、握手、响应头等阶段分别限制，必要时再结合
context做更细粒度控制。
归根结底，Go 的 net/http 已经提供了足够好的基础能力，问题通常不是“没有连接池”，而是“连接池和超时没有按业务负载调好”。对于高并发服务来说，默认配置可以作为起点，但不应该作为终点。把这些关键参数调到位，再配合正确的响应体处理和客户端复用，性能和稳定性通常都会有明显改善。
