Go net/http.Transport 连接池为什么没有复用怎样构造最小复现

Go 的 net/http.Transport 连接池没有复用时，先别急着把 MaxIdleConnsPerHost 调大。最常见的原因是每次请求都新建了 Transport，或者响应体没有读完并关闭，连接没有机会安全回到空闲池。最小修复是让多个请求共享同一个 http.Client，对每个 Response.Body 做完处理后关闭，再用 httptrace.GotConnInfo 的 Reused 和 WasIdle 观察结果。

官方地址：https://pkg.go.dev/net/http.Transport

判断“连接池没有复用”不能只看请求耗时。把连接获取、响应体归还和服务端关闭行为拆开记录，第二次请求出现 Reused=true、WasIdle=true，才说明它确实从空闲池拿到了连接。

先确认 Transport 是否真的被复用

Transport 本身维护连接状态，官方文档建议复用实例，而不是每次调用都创建。下面这种写法会让每个请求拥有一个全新的连接池，日志里自然看不到复用：

func badRequest(ctx context.Context, url string) (*http.Response, error) {
    // 每次创建 Transport，前一次请求的空闲连接无法被本次使用
    client := &http.Client{Transport: &http.Transport{}}
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }
    return client.Do(req)
}

把 Transport 和 Client 提到长生命周期对象中，通常就是第一步修复。它们可以被多个 goroutine 并发使用，不需要为每次请求加一层“临时客户端”。

用 httptrace 构造最小复现

最小复现不必依赖外部网站。用本地 httptest.Server 返回一段短文本，连续发送两次请求，并在 GotConn 中打印复用字段即可。第二次请求前必须先处理并关闭第一次响应体：

func get(ctx context.Context, client *http.Client, url string) error {
    trace := &httptrace.ClientTrace{
        // Reused 表示连接曾用于其他请求，WasIdle 表示本次从空闲池取得
        GotConn: func(info httptrace.GotConnInfo) {
            fmt.Printf("reused=%t idle=%t idle_time=%s\n", info.Reused, info.WasIdle, info.IdleTime)
        },
        // HTTP/1.1 连接归还空闲池时会进入这里；非 nil 表示归还失败
        PutIdleConn: func(err error) {
            fmt.Printf("put_idle_err=%v\n", err)
        },
    }
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return err
    }
    req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    // 读到 EOF 再关闭，让 Transport 有机会复用 HTTP/1.1 连接
    _, copyErr := io.Copy(io.Discard, resp.Body)
    closeErr := resp.Body.Close()
    return errors.Join(copyErr, closeErr)
}

测试时创建一次 Transport：

transport := &http.Transport{
    // 给每个目标主机保留足够的空闲连接，0 表示使用默认值
    MaxIdleConnsPerHost: 4,
    IdleConnTimeout:     30 * time.Second,
}
client := &http.Client{Transport: transport}

// 同一个 client 连续调用两次，第二次才有机会命中空闲池
if err := get(context.Background(), client, server.URL); err != nil {
    log.Fatal(err)
}
if err := get(context.Background(), client, server.URL); err != nil {
    log.Fatal(err)
}

如果两次都显示 reused=false，再看 put_idle_err 和服务端行为；不要先假设是连接池容量不足。

Response.Body 是连接能否归还的关键

只写 defer resp.Body.Close() 并不等于已经消费完响应。短响应有时仍可能被内部处理，但排障和生产代码不能依赖这个偶然结果。需要读取响应内容时用 io.Copy 或明确的解码器，读取后再关闭；如果业务只需要状态码，也要根据响应大小和协议边界决定是否消费剩余内容。

如果服务端提前关闭、响应体读取返回错误，或客户端在 body 完成前就取消请求，Transport 会放弃这条连接。此时新建连接是正确行为，并不是连接池失效。

四个参数与服务端边界

HTTPS 还要区分 HTTP/1.1 与 HTTP/2：httptrace 的 PutIdleConn 对 HTTP/2 不适用，不能拿 HTTP/1.1 的日志规则直接判断 HTTP/2。先看 GotConnInfo，再结合协议和服务端配置分析。

一份可执行的复查清单

先确认所有请求共享同一个 Transport；再给每次请求加 GotConn，记录 Reused、WasIdle 和 IdleTime；然后检查响应体是否读完并关闭。若仍不复用，查看 PutIdleConn 的错误、Keep-Alive 参数、代理和服务端 Connection 头，最后才调整空闲连接上限。

常见问题

为什么只设置 defer Close 仍然没有复用？

关闭是必要条件，但不总是充分条件。响应体提前关闭、读取错误、服务端主动断开或 Transport 已被重复创建，都会让连接不能复用。

MaxIdleConnsPerHost 设成 1 就一定只能复用一条连接吗？

它限制的是每个主机保留的空闲连接数量，不等于整个请求过程只能建立一条连接；并发请求、活动连接和协议版本仍会影响结果。

为什么 HTTP/2 看不到 PutIdleConn？

官方文档说明这个钩子当前不用于 HTTP/2。HTTP/2 的连接可以承载多个并发请求，应使用 GotConnInfo 和协议配置判断，而不是等待 HTTP/1.1 的空闲池回调。

连接池复用的排查顺序可以固定为：共享 Transport，完整处理 Body，观察 GotConn，再检查参数和服务端边界。这样构造出的本地最小复现，才能把“没有复用”从猜测变成可定位的证据。