Go Transport 为什么连接池在请求后立即变空

Go 里看到 http.Transport 的空闲连接数量在一次请求后马上变成 0，通常不代表连接池坏了。更常见的情况是：连接还处于 active 状态、响应体没有读完并关闭、Keep-Alive 被关闭、空闲连接已被回收，或者程序每次请求都新建了 Transport。

判断重点不是“请求结束时有没有一条 idle 连接”，而是下一次请求是否复用了同一个 Transport，以及连接为什么没有进入或停留在 idle 状态。先确认响应体生命周期，再核对 Transport 生命周期和几个容易混淆的参数。

官方资料：https://pkg.go.dev/net/http#Transport

先判断连接池里的连接处于什么状态

Transport 缓存的是可供后续请求复用的 keep-alive 连接。请求正在发送、等待响应或读取响应体时，连接并不属于 idle；只有这次请求对连接的使用结束，并且连接仍满足复用条件，它才可能回到空闲缓存。因此，在请求回调刚结束时读取到 0，不能单独证明没有复用。

还要区分三种观察结果：

• active：请求或响应仍在使用连接，连接池不会把它当作可立即复用的 idle 连接。
• idle：请求已经结束，连接暂时保留给同一主机的后续请求。
• closed：连接被服务端、客户端配置、空闲超时或协议条件关闭，不能再进入复用池。

Go 官方文档也说明，Transport 默认会缓存连接，Transport 应该复用而不是按需创建。排查时不要只盯着一个瞬时连接数，要把“同一个 Transport + 连续两次请求 + 是否 Reused”放在一起看。

最容易漏掉的是 Response.Body 的生命周期

客户端收到响应后，调用方负责关闭 Response.Body。如果只判断状态码就返回，或者在读取过程中提前退出，没有把 body 正确关闭，Transport 就无法稳定地把这条连接交回复用路径。对需要复用的普通响应，常见写法如下：

resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close() // 先登记关闭动作，避免错误分支忘记释放响应体

body, err := io.ReadAll(resp.Body) // 读完响应体，给连接回收和复用留下完整边界
if err != nil {
    return err // 读取失败时仍会执行 defer，确保响应体被关闭
}

_ = body // 这里按业务解析 body；示例只关注 Transport 的资源边界
return nil

如果业务只需要响应头，不要把“只关心状态码”理解成“可以不处理 body”。可以按业务决定是否读取剩余内容，但无论哪种路径，都要明确关闭责任。对同一服务的高频请求，建议把 body 的读取、关闭和错误处理封装在同一个函数里，避免不同调用方各自遗漏。

四个参数分别控制什么

看到连接池变空时，最容易把所有问题都归因于 MaxIdleConnsPerHost。实际上它只控制“每个主机最多保留多少条 idle keep-alive 连接”，不负责创建连接，也不保证一定有连接留下。

MaxIdleConns 还会从所有主机总量角度限制 idle 连接。多目标服务场景下，即使每个主机的 MaxIdleConnsPerHost 足够，整体上限也可能让旧连接被淘汰。参数应按请求并发、目标主机数量和请求间隔一起设定，不能只把某个数字调大。

确认 Transport 是否真的被复用

下面这种写法会让连接池看起来永远是空的：每次调用都创建新的 http.Client 和 http.Transport。新 Transport 没有上一轮请求留下的缓存，自然不能承担跨请求复用。

var sharedClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        100, // 控制所有主机的 idle 连接总量
        MaxIdleConnsPerHost: 20,  // 为单个目标主机保留更多 idle 连接
        IdleConnTimeout:     90 * time.Second, // 空闲连接超过此时长后允许回收
    },
    Timeout: 15 * time.Second, // 限制一次请求的总耗时，避免调用方无限等待
}

func fetch(ctx context.Context, url string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return err // URL 或请求构造失败时不进入 Transport
    }

    resp, err := sharedClient.Do(req) // 多次调用共享同一个 Transport
    if err != nil {
        return err
    }
    defer resp.Body.Close() // 每次响应都由当前调用方负责关闭

    _, err = io.Copy(io.Discard, resp.Body) // 读完 body，给连接复用留下完整响应边界
    return err
}

共享 Transport 不等于无限保留连接。它只是让后续请求有机会从同一缓存中取连接；真正能否复用，还取决于响应体是否处理完、服务端是否允许保持连接、请求是否把连接标记为关闭，以及空闲时间是否超过回收条件。

用 httptrace 观察“有没有复用”

如果日志只记录“请求完成”，很难知道连接池发生了什么。可以用 httptrace.ClientTrace 记录连接获取信息，重点观察 Reused、WasIdle 和 IdleTime。这属于请求级证据，不需要把连接池内部状态当成公开计数器。

trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        log.Printf("reused=%t was_idle=%t idle_time=%s", info.Reused, info.WasIdle, info.IdleTime)
        // Reused=true 说明本次请求拿到了之前建立的连接；不是每次都必须为 true。
    },
}

req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace)) // 把观察点绑定到当前请求
resp, err := sharedClient.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close() // 观察连接不改变响应体的关闭责任
_, err = io.Copy(io.Discard, resp.Body) // 读完响应体后再比较下一次请求的 Reused 值
return err

如果连续请求中偶尔出现 Reused=true，说明 Transport 具备复用能力，某次 idle 为 0 可能只是回收或请求间隔造成的正常结果。如果始终为 false，再按“是否共享 Transport → 是否关闭 Keep-Alive → 是否正确处理 body → 是否存在服务端关闭/协议差异”的顺序排查。

把“变空”分成五种情况

1. 观察时仍在请求中：连接属于 active，等响应结束后再判断。
2. 响应体没有被完整处理：补齐读取和关闭责任，避免把资源释放交给不明确的调用方。
3. Keep-Alive 被关闭：检查 DisableKeepAlives、请求关闭标记和服务端连接策略。
4. 空闲连接已自然回收：对照 IdleConnTimeout、总量上限、每主机上限和两次请求的时间间隔。
5. Transport 没有复用：把 Client/Transport 提升到合适的长生命周期位置，避免每次请求重新创建。

最后不要为了让某个瞬时指标“看起来不为 0”而盲目增大连接上限。更有价值的判断是：同一 Transport 在真实请求间隔下能否复用、响应体是否可靠关闭、连接数是否与目标主机数量和并发规模匹配。

相关问题

MaxIdleConnsPerHost 设置很大，为什么 idle 还是 0？

该字段只是上限，不会强行创建连接。没有可复用的空闲连接、Keep-Alive 被关闭、连接刚被回收，或者 Transport 不是同一个实例时，idle 仍然可能为 0。

调用 CloseIdleConnections 会关闭正在使用的连接吗？

不会。它针对已经处于 idle keep-alive 状态的连接，正在使用的连接不属于这个关闭范围。

是不是必须让每次请求都复用连接？

不必须。低频请求、服务端明确关闭连接或请求之间间隔很长时，连接自然回收是合理的。需要关注的是高频场景是否出现不必要的新建连接和额外延迟。