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

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

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

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

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 放在请求循环外，或通过依赖注入传入，通常比调参数更先解决问题。

用 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、服务端是否主动关闭连接，以及响应体是否在所有分支结束。

一次改造里要比较哪些方案

我更建议把问题拆成三层，而不是上来就把连接上限调大。

• 响应体处理：这是代码正确性问题。先补齐成功、异常和提前返回分支的关闭与消费。
• 客户端生命周期：这是架构边界问题。让同一组下游请求共享稳定的 Transport。
• 连接参数：这是容量问题。只有前两层稳定后，调节空闲数和空闲时长才有意义。

如果下游返回体很大、响应经常被取消，不能简单地把“读到 EOF”当成硬规则。应按接口语义选择上限读取、流式处理或明确放弃复用，并把这个选择写进测试和监控说明。

上线前用一组小实验验收

测试服务可以返回固定大小的响应，并在客户端连续请求同一个地址。验收至少覆盖这四种结果：

1. 正常响应：Body 读取完成，后续请求能观察到复用。
2. 非成功状态：状态判断提前返回，但 Body 仍被消费并关闭。
3. 读取中断：下游连接提前断开，错误被记录，后续请求不会误判为复用。
4. 客户端停止：服务退出时调用自定义 Transport 的空闲连接清理动作。

日志里建议同时保留下游主机、状态码、响应字节数、连接是否复用和请求耗时。这样连接复用下降时，能区分是业务分支漏了关闭，还是对端真的在主动断开。

常见问题：连接复用排查的几个边界

只调用 Close 不读取 Body 可以吗？

可以释放响应体资源，但不一定能让 HTTP/1.1 持久连接回到可复用状态。只关心小响应时，通常应先按上限读取再关闭。

把 DisableKeepAlives 设为 true 能解决连接数问题吗？

它会关闭持久连接复用，可能让空闲连接减少，却把问题变成更多握手和更高延迟。除非有明确的协议或隔离需求，不应把它当作连接池泄漏修复。

为什么本地测试复用很好，线上却很差？

线上可能经过代理、网关或多个下游主机，也可能有更多异常响应分支。用 GotConnInfo 记录真实请求路径，再按主机和状态码拆分，通常比只看总连接数更快定位。

把“连接回池”变成可验证的工程约束

这类问题最终不是某一个参数的胜负。先保证每个响应分支都正确结束，再让 Transport 复用，最后用 httptrace 和连接指标确认结果。代码审查时盯住 Do 之后的所有 return，压测时盯住同一主机的复用比例，连接池才不会在流量上来后悄悄失去作用。