当前位置：首页 > 文章列表 > Golang > Go教程 > Go HTTP 客户端连接池为什么越用越散：Body 读取、Transport 复用与 httptrace 验收

Go HTTP 客户端连接池为什么越用越散：Body 读取、Transport 复用与 httptrace 验收

来源：17golang原创 2026-08-11 12:53:09 0浏览收藏

线上一个 Go 网关的下游请求量没有明显增加，连接数却从几百慢慢爬到几千。抓日志后发现，问题不在服务端连接数限制，而在客户端把每次请求都当成了一次性连接：有的分支只看状态码就返回，有的分支每次循环都创建新的 Transport。修好这两处后，再用 httptrace 观察连接是否来自池中，才能确认“连接复用”真的发生了。

实践要点

成功拿到响应后，Response.Body 要关闭；希望 HTTP/1.1 连接回池时，还要尽量把 Body 读到 EOF。
http.Transport 应作为长生命周期对象复用，不要在每次请求里重新创建。
不要只看请求耗时，用 httptrace.GotConnInfo.Reused 验收连接是否复用。

连接数为什么会在请求结束后继续上涨

先看一个很容易藏在业务分支里的写法：

resp, err := client.Do(req)
if err != nil {
    return err
}
if resp.StatusCode != http.StatusOK {
    return fmt.Errorf("downstream status: %s", resp.Status)
}
return nil

这段代码有两个问题。第一，返回前没有关闭 resp.Body；第二，即使把关闭补上，如果只读了响应头而没有消费响应体，HTTP/1.1 的持久连接也可能无法回到可复用状态。偶发错误分支通常最难发现，因为正常响应路径可能已经写了 io.Copy，只有 4xx、5xx 或业务提前返回时才泄漏复用机会。

先把响应体的生命周期收紧

如果调用方只关心状态码，可以明确消费一个有上限的响应体，再关闭它。这里的上限是业务约束，不是越大越好：

func checkDownstream(ctx context.Context, client *http.Client, endpoint string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
    if err != nil {
        return err
    }

    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    _, readErr := io.Copy(io.Discard, io.LimitReader(resp.Body, 1= 300 {
        return fmt.Errorf("downstream status: %s", resp.Status)
    }
    return nil
}

这里的顺序值得保留：拿到非空响应后立刻登记关闭动作，随后按业务允许的大小读取。若响应体本身需要解析，就直接交给 JSON 解码器或流式读取器；不要为了“复用连接”把可能是几十 MB 的下载内容全部读进内存。

Transport 要跟着客户端一起长寿命

http.Client 可以并发使用，底层 Transport 也应复用。一个服务里通常在初始化阶段建立它：

var sharedClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 20,
        IdleConnTimeout:     90 * time.Second,
    },
    Timeout: 5 * time.Second,
}

参数没有万能答案。MaxIdleConnsPerHost 太小，突发流量会频繁新建连接；盲目调得很大，又会让空闲连接占住文件描述符和服务端配额。先根据下游主机数量、并发峰值和空闲时长估一个范围，再观察连接建立次数和请求延迟。

尤其不要这样写：

func call(ctx context.Context, url string) error {
    client := &http.Client{Transport: &http.Transport{}}
    // 每次调用都会得到一套新的连接缓存
    _ = client
    return nil
}

即使没有 Body 泄漏，每次创建 Transport 也会切断此前积累的空闲连接。把 client 放在请求循环外，或通过依赖注入传入，通常比调参数更先解决问题。

Go HTTP 客户端从请求到下游响应的调用链，突出 Response Body 未读取关闭导致连接无法回池的瓶颈

用 httptrace 证明连接是否真的复用

压测时只看平均耗时不够，因为新建连接和复用连接都可能在低流量下表现正常。可以用 httptrace.ClientTrace 记录每次拿到连接时的状态：

var reused bool
trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        reused = info.Reused
        log.Printf("got conn reused=%v was_idle=%v idle_time=%s",
            info.Reused, info.WasIdle, info.IdleTime)
    },
}

req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close()
_, _ = io.Copy(io.Discard, resp.Body)
log.Printf("status=%s reused=%v", resp.Status, reused)

验收时不要只抓一条请求。连续发同一主机的多次请求，确认首个请求可能是 reused=false，后续请求在响应体完整读取并关闭后出现 reused=true。如果始终是 false，再检查是否每次换了 Transport、服务端是否主动关闭连接，以及响应体是否在所有分支结束。