Go HTTP 客户端怎么复用 Transport 并设置连接池上限

Go 的 HTTP 连接池应该跟着 Transport 复用，而不是跟着每一次请求临时创建。把一个配置好的 *http.Transport 放进长期存活的 http.Client，多个请求就能共享 keep-alive 连接；再用 MaxIdleConnsPerHost、MaxConnsPerHost 和 IdleConnTimeout 分别控制“留多少空闲连接”“同一主机最多有多少连接”“空闲多久回收”。

最小可靠做法是：一个目标服务复用一个 Transport，正确关闭并消费响应体；先按单主机并发设置 MaxConnsPerHost，再用 MaxIdleConnsPerHost 保留可复用的空闲连接。

先复用 Transport，再决定连接池上限

http.Client 负责更高层的请求使用方式，真正维护连接缓存的是它的 Transport。官方文档明确建议复用 Transport，并说明它可以被多个 goroutine 并发使用。常见错误是把 &http.Client{} 或 &http.Transport{} 写进请求函数，这样配置无法形成稳定的连接缓存，也容易让超时和连接策略散落在各处。

可以先把 Transport 集中在构造函数中：

package main

import (
    "context" // 提供请求取消和截止时间
    "io"      // 消费响应体，帮助连接回到可复用状态
    "net/http"
    "time"
)

func newHTTPClient() *http.Client {
    transport := &http.Transport{
        MaxIdleConns:        100,              // 所有目标主机共享的空闲连接上限
        MaxIdleConnsPerHost: 16,               // 每个目标主机保留的空闲连接数
        MaxConnsPerHost:     32,               // 每个目标主机的连接总数，包含活跃和空闲
        IdleConnTimeout:     90 * time.Second, // 空闲连接超过此时间后回收
    }
    return &http.Client{
        Transport: transport,
        Timeout:   10 * time.Second, // 保护一次请求的总耗时
    }
}

func fetch(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) // 读完响应，给连接复用留下机会
    return err
}

这里的数字只是示例，不是通用性能答案。关键是 transport 只创建一次，并且每次请求都让响应体走完生命周期。若业务只读取少量响应，仍应根据响应格式决定是否继续消费；不能为了“连接池复用”无条件吞掉超大的响应体。

MaxIdleConnsPerHost 和 MaxConnsPerHost 怎么配

这两个字段最容易被混淆。MaxIdleConnsPerHost 约束的是某个主机保留多少条 keep-alive 空闲连接；MaxConnsPerHost 则覆盖拨号中、正在使用和空闲的连接总数。达到总连接上限时，后续拨号会等待，因此它会直接影响高并发请求的排队表现。

配置时可以先问三个问题：单个目标主机的最大并发是多少？请求是否集中在少数主机？空闲连接需要多快释放？例如单主机并发大约 24，可以先把 MaxConnsPerHost 放在略高于并发峰值的位置，再把 MaxIdleConnsPerHost 设为能覆盖常态并发的较小值。多个主机同时访问时，还要检查 MaxIdleConns 是否成为总的空闲连接瓶颈。

响应体、HTTP/2 和关闭时机决定实际效果

连接池参数只描述允许的边界，不保证每个请求都会复用一条 TCP 连接。服务端主动关闭、TLS/代理策略、HTTP/2 多路复用以及响应体没有读完，都会改变最终表现。尤其是 HTTP/2，多个请求可能共享一条连接，此时不能用“连接条数”简单推断并发请求数。

程序准备停止接收新请求时，可以对自建 Transport 调用 CloseIdleConnections 清理空闲连接；不要在每个请求完成后调用它，否则刚放回池中的连接会立即失去复用价值。若只是想限制单次请求等待，应使用 Client.Timeout 或请求上下文，而不是把 IdleConnTimeout 当作请求超时。

常见问题

http.Client 和 Transport 能被多个 goroutine 共用吗？

可以。Transport 设计为可并发使用，Client 也适合长期复用。共享前提是不要在请求进行时随意改写 Transport 字段。

MaxIdleConnsPerHost 能限制并发请求吗？

不能。它只限制请求结束后保留的空闲连接数量；要限制同一主机的连接总数，应看 MaxConnsPerHost。

为什么设置了连接池仍然出现新建连接？

先检查是否每次都新建 Transport、是否及时关闭并消费响应体，再确认服务端是否关闭 keep-alive，以及请求是否实际走 HTTP/2 或代理。

把 Transport 当作长期存在的连接策略对象，再按“总连接—空闲连接—回收时间”的顺序调参，通常比单独增大某一个池大小更容易解释，也更容易在流量变化时回滚。