Go Transport 连接池参数调大后延迟反而升高怎么办

把 http.Transport 里的连接数一口气调大，延迟却变高，通常不是 Go 的连接池“越大越慢”，而是把空闲连接容量和实际并发上限混在了一起。先确认 Client 和 Transport 在请求之间复用，再检查 Response.Body 是否读完并关闭，最后才根据上游能承受的并发设置边界。

先别急着继续调大：三个连接池参数不是一回事

最容易误判的是把三个参数都叫“连接池大小”。MaxIdleConns 是所有主机合计的空闲连接上限，MaxIdleConnsPerHost 是单个主机保留多少空闲连接；它们解决的是请求间歇期能否快速复用。MaxConnsPerHost 则限制单主机的总连接数，包含正在拨号、正在使用和空闲的连接，达到上限后新的拨号会等待。

先确认 Client 和 Transport 没有跟着请求一起销毁

官方文档明确建议复用 Client 和 Transport。若每次调用都创建一个新的 Transport，调大空闲参数也只是在许多短命对象上分散配置，连接缓存无法跨请求发挥作用；若把共享 Transport 的并发上限直接抬高，又可能让上游服务、代理和本机同时面对更多连接。

把客户端放在服务对象或依赖注入容器中，按上游地址和代理/TLS 配置做隔离。不要在请求进行时修改共享 Transport；如果确实需要两套策略，就创建两套长期存在的 Client。

Body 不释放，池子再大也救不了复用

Client.Do 成功返回时，调用方负责关闭 Response.Body。对需要连接复用的正常响应，应该读取到 EOF 后再关闭；只看状态码就提前返回，会让 Transport 无法稳定复用这条 HTTP/1.x keep-alive 连接。Go 会在关闭时尝试异步读取一部分剩余内容，但这不是任意大响应都能完整复用的保证。

package main

import (
    "fmt"
    "io"
    "net/http"
    "time"
)

// Client 和 Transport 在服务生命周期内复用，避免每次请求丢掉连接缓存。
var client = &http.Client{
    Timeout: 5 * time.Second,
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 20,
        MaxConnsPerHost:     40,
        IdleConnTimeout:     90 * time.Second,
    },
}

func fetch(url string) ([]byte, error) {
    resp, err := client.Get(url)
    if err != nil {
        return nil, err
    }
    // 拿到响应后立刻登记释放动作，错误分支也不会遗留 Body。
    defer resp.Body.Close()

    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("unexpected status: %s", resp.Status)
    }
    // 读取到 EOF，让 Transport 有机会复用 keep-alive 连接。
    data, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }
    return data, nil
}

用可观测信号判断是排队、重连还是上游变慢

不要只看一个平均耗时。先记录请求是否复用了连接，再把总耗时拆成连接建立、等待响应头和读取响应体。若复用率下降，优先查 Client/Transport 是否被重复创建以及 Body 是否提前结束；若复用率正常但等待时间上升，重点看 MaxConnsPerHost、上游限流、代理队列和本机资源。

下面这张清单适合放在一次灰度复查中：

一套更稳的修复顺序

先把 Client 和 Transport 提到请求循环之外，保证每个成功响应都消费并关闭 Body；再只提高与实际症状对应的空闲参数；只有确认上游和本机都能承受时，才逐步提高 MaxConnsPerHost。每次变更都同时观察 p95、错误率、连接复用情况和上游响应时间。

如果程序退出、测试结束或明确更换 Transport，可以调用 client.CloseIdleConnections() 清理空闲连接；它不应该变成每次请求后的固定动作，否则会主动削弱连接复用。

相关问题

MaxIdleConnsPerHost 越大，吞吐就一定越高吗？

不一定。它主要增加可保留的空闲连接，是否有收益取决于请求是否突发、上游是否允许复用以及 Body 是否正确释放。

MaxConnsPerHost 设为零是不是最省心？

零表示不限制，但不代表上游、代理和本机资源没有上限。生产环境通常需要结合上游承载能力做一个可解释的边界。

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

可以释放响应资源，但对需要复用的正常响应，读到 EOF 再关闭更稳妥；大响应或异常响应可按业务限制读取大小后关闭。