Go http.Transport 空闲连接为什么复用不上：连接池参数、响应体关闭与复用核对

线上服务把 Go 客户端换成了复用 http.Transport 的写法，连接数却没有降下来。先看最容易漏掉的一点：响应返回后，Body 不仅要关闭，通常还要读到 EOF，Transport 才有机会把这条持久连接放回池里；如果每次请求都新建 Transport，前面的连接池也不会被后续请求共享。

把 Transport 当成长生命周期对象复用，成功响应按需读完并关闭 Body，再根据同一主机的并发量设置空闲连接上限。连接复用是否生效，要用请求追踪或服务端连接日志核对，不能只看代码里有没有一个 Transport 变量。

先把连接复用的三个前提对齐

Transport 是低层 RoundTripper，官方文档建议复用它；默认 Transport 会缓存连接供后续请求使用。这里有三个前提经常被混在一起：

• 请求发往同一个网络端点，协议、主机和端口要能落到同一连接池。
• 响应体要被正确消费并关闭，客户端才可能复用持久 TCP 连接。
• 连接必须还没被服务端、代理或 IdleConnTimeout 淘汰。

所以“连接池参数已经加大”并不等于一定复用。先确认生命周期和 Body，再看参数，排查会快很多。

最小可用写法：Transport 只创建一次

把客户端放在业务对象或进程级依赖里，避免在每个函数调用中重新初始化。只需要状态码的场景，可以把响应内容读完再关闭：

tr := &http.Transport{
    MaxIdleConns:        100,
    MaxIdleConnsPerHost: 20,
    IdleConnTimeout:     90 * time.Second,
}
client := &http.Client{Transport: tr}

func checkEndpoint(ctx context.Context, client *http.Client, url string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return err
    }
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    _, err = io.Copy(io.Discard, resp.Body)
    if err != nil {
        return err
    }
    if resp.StatusCode = 300 {
        return fmt.Errorf("unexpected status: %s", resp.Status)
    }
    return nil
}

这段代码的关键不是三个数字，而是 client 和 tr 的生命周期，以及 io.Copy 与 Close 的顺序。若业务必须提前停止读取，可以接受这次连接不复用，不要为了“省几次读取”而假定连接一定会回池。

为什么 Body 没处理好会让连接池看起来失效

调用 client.Do 后，返回的 Response.Body 由调用方负责关闭。只写 defer resp.Body.Close() 能避免资源长期泄漏，但在 HTTP/1 持久连接场景，响应内容没有读完时，Transport 未必能把底层连接交给下一次请求。

下面几种写法都值得在代码审查中标出来：

• 只判断 resp.StatusCode 就直接返回。
• 遇到非 2xx 状态时直接关闭，没有读取一个很小的错误响应。
• 把 Body 交给上层，却由多个层级分别负责关闭。

处理办法不是无条件把大响应读入内存，而是按接口协议设定上限。例如错误体只需要日志摘要，可以用带限制的读取，再关闭 Body；大文件下载则按流式消费，直到下载逻辑明确结束。

三个参数分别解决什么问题

MaxIdleConnsPerHost：单主机空闲连接上限

它控制每个主机最多保留多少条空闲 keep-alive 连接。并发请求如果集中访问同一个 API，默认值可能偏小；调大后也只表示“允许多留一些空闲连接”，并不保证服务端接受 keep-alive。

MaxIdleConns：所有主机的空闲连接总上限

程序访问很多域名时，总上限会影响连接池的整体保留量。单主机上限很大，但总上限较小，仍可能出现空闲连接被快速淘汰。

IdleConnTimeout：空闲连接最长保留时间

它只针对空闲状态，不是请求响应超时。若上游网关的 keep-alive 时间比客户端更短，客户端保留的连接也可能在下一次使用时失效，Transport 会重新建立连接，这是正常恢复路径。

用追踪和服务端日志确认到底有没有复用

不要用“看到连接数下降”作为唯一结论。客户端可以给请求挂上 httptrace.ClientTrace，观察 GotConn 回调里的 Reused 和 WasIdle；服务端则对照同一客户端地址、请求时间和连接编号。

trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        log.Printf("reused=%v idle=%v idleTime=%v", info.Reused, info.WasIdle, info.IdleTime)
    },
}
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

如果连续请求的 Reused 一直为 false，按这个顺序查：请求是否真的共用 Client、Body 是否读完并关闭、请求是否跨了不同主机、服务端是否主动关闭、空闲时间是否超过双方任一侧的限制。

常见误区与边界

把每次请求建 Transport 当成“更安全”

Transport 本身支持并发使用。反复创建会切断连接池共享，还会增加握手和连接回收压力；需要隔离配置时，按配置组维护少量长期对象。

把 MaxConnsPerHost 当成空闲池大小

它限制每个主机的总连接数，包含拨号中、活跃和空闲连接；设置过小会让并发请求排队。它和 MaxIdleConnsPerHost 解决的是两件事。

只在压测结束时调用 CloseIdleConnections

这个方法适合测试收尾、凭据切换或明确的生命周期结束点。在线请求路径反复调用，会主动清空本来可以复用的连接。

一份可落地的复用验收清单

1. 确认 Client 和 Transport 在多次请求之间保持同一实例。
2. 确认所有成功与失败分支都关闭 Body，流式响应有明确的消费边界。
3. 用 httptrace 记录至少一组连续请求的 Reused 结果。
4. 按单主机并发量设置 MaxIdleConnsPerHost，再核对网关的 keep-alive 时间。
5. 压测结束后再调用 CloseIdleConnections，观察资源是否回收。

最终判断应该来自同一批请求的追踪记录，而不是某个参数“看起来很大”。当 Body 生命周期、Transport 生命周期和上下游空闲策略都对齐，连接复用才会稳定出现。

相关问题

只调用 Body.Close，不读响应内容可以吗？

可以释放这次响应的资源，但不能把“关闭”理解成一定复用连接。HTTP/1 场景优先读到 EOF，再关闭；具体还要考虑响应大小和业务是否允许继续消费。

Client 可以被多个 goroutine 共用吗？

可以，官方文档把 Client 和 Transport 都设计为可并发使用。共享时要把请求级 Header、Body 和上下文放在各自请求上，不要并发改同一个请求对象。

HTTPS 一定能看到 Reused 吗？

不一定。HTTP/2 的复用模型与 HTTP/1 连接池不同，代理、服务端配置和协议协商也会影响观察结果，应该结合 trace 的协议与连接信息判断。

总结

Go 的连接复用首先是生命周期问题，其次才是参数问题。复用长期存在的 Client/Transport，正确消费并关闭 Body，用 GotConn 记录事实，最后再根据单主机并发与上游 keep-alive 调整池大小，通常比盲目把数字调大更有效。