你的 Go 服务为何在高并发下变慢？可能是 HTTP 连接池没配好

你可能见过这样的情况：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 接入、高并发热点接口，对连接数和超时的要求都可能不同。全部共用同一套配置，通常很难跑到最优。

简单说，客户端配置应该跟着调用特征走，而不是图省事全部统一。

实战配置建议：从能用到跑稳

把上面的参数和常见问题放到一起看，线上实践里最值得坚持的其实就四条：

1. 先调连接池，再谈吞吐。 重点关注 MaxIdleConnsPerHost、MaxIdleConns 和 MaxConnsPerHost，并通过压测验证。像 MaxIdleConnsPerHost 设为预期并发数的 1/3 到 1/2，往往是比较实用的起点。
2. 始终读取并关闭响应体。 这是连接能否复用的前提。少了这一步，连接池配置得再好也会失效。
3. 复用同一个或少量客户端实例。 绝对不要为每个请求单独创建新的 http.Client，否则连接池几乎没有发挥空间。
4. 把超时拆到不同阶段。 除了总超时，还要按建连、握手、响应头等阶段分别限制，必要时再结合 context 做更细粒度控制。

归根结底，Go 的 net/http 已经提供了足够好的基础能力，问题通常不是“没有连接池”，而是“连接池和超时没有按业务负载调好”。对于高并发服务来说，默认配置可以作为起点，但不应该作为终点。把这些关键参数调到位，再配合正确的响应体处理和客户端复用，性能和稳定性通常都会有明显改善。