Go HTTP 连接池为什么出现大量空闲连接

Go HTTP 连接池里出现空闲连接，通常不是连接泄漏，而是 Transport 为了复用 keep-alive 连接主动保留了它们。真正需要排查的是：空闲连接是否超过业务规模、是否因为响应体没有正确关闭而无法复用，以及短生命周期任务是否需要主动清理。

官方文档：https://pkg.go.dev/net/http

先复用同一个 http.Transport，再用 MaxIdleConnsPerHost、MaxIdleConns 和 IdleConnTimeout 设边界；请求结束时始终关闭 Response.Body。只有批处理阶段切换或客户端即将退出时，才调用 CloseIdleConnections。

先判断空闲连接是否真的异常

Transport 会按目标主机维护连接状态。请求完成后，仍可复用的连接会进入 idle keep-alive 状态，下一次访问同一主机可以跳过重新建连。Go 官方源码中的默认配置包含总空闲连接上限、空闲超时和每主机默认值；因此监控里看到 idle 并不等于 goroutine 或 TCP 资源泄漏。

先按三个维度看现象：

• 只有一个主机时，重点看 MaxIdleConnsPerHost 是否被调得过大。
• 访问很多主机时，重点看总量 MaxIdleConns，因为每个主机都可能留下少量连接。
• 请求已经停止很久仍不下降时，检查 IdleConnTimeout 是否为零；零值表示不设空闲时间限制。

检查响应体和 Transport 是否可复用

最容易被忽略的是 Response.Body。调用 Client.Do 成功后，调用方负责关闭响应体；如果响应体既没有读完也没有关闭，底层 Transport 可能无法复用这条持久连接。连接数持续增长时，应先搜所有请求路径是否都有关闭动作，尤其是提前返回和非 2xx 分支。

resp, err := client.Do(req)
if err != nil {
    // 请求失败时没有可关闭的响应体。
    return err
}
defer resp.Body.Close() // 无论后续解析是否成功，都释放响应体。

body, err := io.ReadAll(resp.Body)
if err != nil {
    // 读取失败仍由 defer 负责关闭，避免连接状态悬挂。
    return err
}
_ = body // 示例只关注 Body 生命周期，业务代码在这里解析内容。

如果只是探活而不需要响应内容，也不要把“无需读取”误解成“无需关闭”。可以按业务需要读取少量内容，但关闭动作仍应保留。

用 Transport 参数收紧连接池边界

如果业务确实访问多个主机，或者并发突发后留下了过多空闲连接，可以显式创建并长期复用一个 Transport。下面的参数分别处理“所有主机总量”“单个主机数量”和“空闲多久自动关闭”，不要只修改其中一个。

tr := &http.Transport{
    MaxIdleConns:        40,              // 所有主机合计最多保留 40 条空闲连接。
    MaxIdleConnsPerHost: 4,               // 同一主机最多保留 4 条空闲连接。
    IdleConnTimeout:     30 * time.Second, // 空闲超过 30 秒后自动关闭。
}
client := &http.Client{Transport: tr}

// 同一个 client 服务多个请求，才能真正获得连接复用收益。
resp, err := client.Get("https://example.com/health")
if err != nil {
    return err
}
defer resp.Body.Close()

MaxIdleConnsPerHost 为零时使用默认值；MaxIdleConns 和 IdleConnTimeout 为零则分别表示不限制总空闲数和不设置空闲时间限制。参数不是越小越好：过小会增加重新建连和 TLS 握手，应该结合主机数量、并发峰值和请求间隔设置。

短任务结束时主动清理

常驻 HTTP 客户端通常让超时策略自然回收即可；批处理、定时任务或租户切换场景则可以在一个阶段结束后调用 CloseIdleConnections。它只关闭当前闲置的 keep-alive 连接，不会中断正在使用的连接。

// 阶段性任务完成后清理闲置连接，不影响仍在处理的请求。
tr.CloseIdleConnections()

不要为每次请求都新建 Transport，这会失去池化和复用；也不要把 DisableKeepAlives 当成默认修复方案，它会牺牲连接复用，只有明确不需要持久连接的边界才考虑它。

排查清单

1. 确认客户端是否复用了同一个 Transport，而不是请求一次创建一次。
2. 确认所有成功响应路径都关闭了 Response.Body，并检查提前返回分支。
3. 按主机数分别核对 MaxIdleConns、MaxIdleConnsPerHost 和 IdleConnTimeout。
4. 短生命周期任务结束时，再决定是否调用 CloseIdleConnections。

总结来说，空闲连接是连接池“准备复用”的状态，不是看到数量上升就必须清空。先修正 Body 生命周期，再根据主机数量和任务周期配置上限，最后用空闲超时或阶段性清理控制尾部资源。

相关问题

为什么连接已经空闲，数量还没有立刻下降？因为连接会等待 IdleConnTimeout，并且参数为零时没有自动时间边界。

每个主机都设置了少量空闲连接，为什么总数仍很大？总量是多个主机的累加，应同时设置 MaxIdleConns。

关闭 Body 后还要调用 CloseIdleConnections 吗？常驻客户端通常不需要；只有阶段结束、客户端退出或明确要切断闲置连接时才需要。