Go HTTP 请求 Body 不关闭为什么连接池复用变差

Go 的 HTTP 客户端里，Response.Body 不是普通返回值，而是一段仍占用响应资源的流。请求成功后如果既不读完也不关闭它，Transport 可能无法把底层持久连接放回空闲池；如果每次请求都新建 http.Client，即使关闭正确，也没有稳定的连接池可以复用。

最稳妥的做法是复用一个长期存活的 http.Client，在确认 err == nil 后立即为 resp.Body 安排 defer Close；需要保留 HTTP/1 连接时，再根据响应大小读到 EOF 或主动丢弃剩余内容。

先看清 Response.Body 的连接复用边界

http.Client.Do 返回的 Response 只是响应外壳，真正承载网络内容的是 Response.Body。底层 Transport 维护连接缓存，客户端下一次请求能否复用 TCP 连接，取决于前一个响应的资源是否已经妥善结束。

因此，下面这种写法的问题不是“少了一行清理代码”这么简单：它会把响应体留在未完成状态，连接可能不能回到空闲连接池。

resp, err := client.Do(req)
if err != nil {
    return err
}
// 这里只取状态码，却遗漏了 Body.Close，响应资源没有明确结束。
return checkStatus(resp.StatusCode)

错误判断要放在前面。发生错误时不能假定 resp 可用；成功后则应立刻建立 Body 的关闭责任。

正确关闭 Body 还要区分读取策略

只调用 Close 能避免资源长期泄漏，但它不等价于“已经读完响应”。对 HTTP/1 请求，未读完的响应内容可能阻止连接复用；小响应通常直接读入内存，大响应或无需保存正文时，可以把剩余内容丢弃后关闭。

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

    resp, err := client.Do(req)
    if err != nil {
        return "", err
    }
    // 成功响应的 Body 由当前函数负责关闭，避免调用方忘记清理。
    defer resp.Body.Close()

    // 小响应需要正文，因此读到 EOF 后再交给上层解析。
    data, err := io.ReadAll(resp.Body)
    if err != nil {
        return "", err
    }
    if resp.StatusCode = http.StatusMultipleChoices {
        return "", fmt.Errorf("unexpected status: %s", resp.Status)
    }
    return string(data), nil
}

若只关心状态码，可以不把全文放进内存，但应明确采用“丢弃剩余内容”的策略：

func probe(ctx context.Context, client *http.Client, url string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodHead, url, nil)
    if err != nil {
        return err
    }
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    // 不需要正文时释放剩余字节，再关闭响应体。
    _, _ = io.Copy(io.Discard, resp.Body)
    return resp.Body.Close()
}

大响应不宜无上限地读取。可以用 io.LimitReader 只取需要的前缀，超过上限时记录“截断”状态；但如果目标是尽量复用 HTTP/1 连接，就要结合响应体大小和带宽成本决定是否继续丢弃。

复用 Client，别让连接池每次重新出生

http.Client 和 Transport 都可以并发使用，适合在服务对象、包级依赖或应用初始化阶段创建一次。循环里写 &http.Client{} 会不断产生新的 Transport 状态，表现出来就像连接池复用变差。

type API struct {
    client *http.Client
}

func NewAPI() *API {
    // 一个 API 实例复用同一个 Transport，连接缓存才有机会跨请求生效。
    return &API{client: &http.Client{Timeout: 8 * time.Second}}
}

不要为了“修复连接泄漏”把 DisableKeepAlives 全局打开。它会改变连接复用策略，可能掩盖 Body 生命周期问题，并增加握手成本。只有明确不需要持久连接时，才把它作为单独的设计决策。

用小范围检查定位复用变差

排查时先做代码层面的三项核对：所有 err == nil 的响应是否都有关闭点；关闭点是否位于同一个拥有响应的函数；请求循环是否复用了同一个 Client。再看请求耗时、下游连接数和超时类型，区分是连接创建变多，还是服务器本身响应变慢。

如果代码由多个分支消费 Body，可以把读取和关闭封装在一个函数中，避免“成功分支关闭、异常分支遗忘”的分叉。日志只记录 URL 主机、状态码、响应字节数和耗时，不要把认证头或完整响应正文写入日志。

常见问题

只调用 resp.Body.Close，不读正文可以吗？

可以避免 Body 一直占用，但 HTTP/1 连接是否能复用还取决于剩余内容是否被处理。对小响应可读完；不需要正文时可谨慎丢弃后关闭。

defer resp.Body.Close 会不会太晚？

只要 defer 所在函数不会长时间持有响应，通常是清晰且安全的写法。不要把它放在一个处理大量请求的长生命周期循环中，否则关闭会拖到整个函数结束。

HTTP/2 也必须关闭 Body 吗？

必须。HTTP/2 使用流而不是简单复用 HTTP/1 TCP 请求，但响应体仍是需要释放的资源；关闭时机仍应与当前请求的消费边界一致。

记住这条判断即可：Client 决定连接池能否长期存在，Response.Body 决定一次响应能否干净退出。先固定两者的生命周期，再讨论连接参数，通常更容易找到真正原因。