HTTP Transport 连接池不复用时的响应体处理

我排查过一个 Go 接口聚合服务：http.Client 和 http.Transport 明明都做成了全局复用，连接数与 TLS 握手却还是持续增加。最后发现问题不在连接池参数，而在几个提前返回的分支——代码有 defer resp.Body.Close()，却没有把响应体读到 EOF。对 HTTP/1.x 来说，想让连接稳定回到空闲池，最稳妥的做法是：小响应体完整读取或丢弃到 EOF，然后关闭 Body；遇到超大或不可信响应体，则优先守住内存与带宽边界，提前关闭并接受这次连接可能不复用。

官方文档：https://pkg.go.dev/net/http#Client.Do

我第一次排查时只盯着 Close

当时的代码看起来很标准：请求成功后立即注册 defer resp.Body.Close()，遇到非 200 状态就返回错误。问题在于，非 200 分支没有读取 Body。Go 官方文档明确说明：当返回错误为 nil 时，响应会带有非空 Body，调用方应关闭它；如果 Body 没有读到 EOF 并关闭，底层 RoundTripper（通常是 Transport）可能无法为后续 keep-alive 请求复用持久 TCP 连接。

这里还要补一个容易被忽略的细节：当前官方文档也说明，关闭 Body 时，Transport 会在一个保守上限内尝试异步读到 EOF。因此很多小响应只调用 Close 也“看起来没问题”，但这不是值得依赖的业务策略，更不能据此忽略巨大响应体、慢响应体和提前返回分支。

连接复用依赖响应体走到 EOF

http.Transport 持有缓存 TCP 连接等内部状态，应该长期复用。一次 HTTP/1.x 响应的边界由协议与响应体共同决定；客户端读到 EOF 后，Transport 才能确认这条连接上上一份响应已经完整结束，再把连接交给后续请求。Body.Close() 则负责释放响应体相关资源。把两者放在一起理解，比把 Close 当成唯一开关更准确。

最小可用处理：读完再关闭

如果响应体很小，而且业务完全不需要内容，我会明确把它复制到 io.Discard。这样代码把“希望复用连接”写成了可见动作，而不是把结果交给 Close 的保守异步读取策略。

package client

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

func ping(client *http.Client, url string) error {
    req, err := http.NewRequest(http.MethodGet, url, nil)
    if err != nil {
        return fmt.Errorf("创建请求失败: %w", err)
    }

    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("发送请求失败: %w", err)
    }
    // 请求成功后立即登记关闭，确保所有返回分支都能释放响应体。
    defer resp.Body.Close()

    // 小响应体且不需要正文时，主动读取到 EOF，便于 HTTP/1.x 连接复用。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return fmt.Errorf("读取响应体失败: %w", err)
    }

    if resp.StatusCode != http.StatusNoContent {
        return fmt.Errorf("服务返回状态码 %d", resp.StatusCode)
    }
    return nil
}

如果业务需要正文，则正常的 io.ReadAll、JSON 解码或流式处理本身就在消费 Body。需要注意的是，解码器完成一个 JSON 值并不必然等于底层流已到 EOF；若服务端可能附加空白或额外字节，而你又要求 HTTP/1.x 连接复用，可以在解码成功后继续读取剩余内容，或改成受控的完整读取再解码。

错误状态码也要处理 Body

Client.Do 不会因为服务端返回 404 或 500 就自动产生 Go 错误。只要协议层请求成功，err 仍可能是 nil，Body 仍归调用方管理。我的习惯是把状态检查放在“已经确定 Body 生命周期”之后：

func requireOK(client *http.Client, req *http.Request) error {
    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("请求失败: %w", err)
    }
    // 即使后面状态码不符合预期，也必须关闭响应体。
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        // 错误页已知很小时，读取到 EOF，让连接有机会回到空闲池。
        if _, err := io.Copy(io.Discard, resp.Body); err != nil {
            return fmt.Errorf("状态码为 %d，且读取错误响应失败: %w", resp.StatusCode, err)
        }
        return fmt.Errorf("服务返回状态码 %d", resp.StatusCode)
    }

    // 正常分支在这里消费业务正文，示例仅演示生命周期。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return fmt.Errorf("读取正常响应失败: %w", err)
    }
    return nil
}

这段代码只适用于“响应体可控且较小”的接口。若上游可能返回数百兆错误页或永不结束的流，就不能机械地 io.Copy 到 EOF。

大响应体不要为了复用无限排空

连接复用不是最高优先级。面对未知 Content-Length、压缩后体积不可预估、下载接口或不可信上游时，我会先设置读取上限。超过上限就停止读取并关闭 Body，此时应把“该连接可能无法复用”视为预期结果，而不是继续消耗带宽和 CPU 去换一次复用机会。

var ErrBodyTooLarge = errors.New("响应体超过 1 MiB 上限")

func readSmallBody(resp *http.Response) ([]byte, error) {
    const maxBody = 1  maxBody {
        // 此时并未读到 EOF；调用方关闭 Body，并接受该连接可能不复用。
        return nil, ErrBodyTooLarge
    }
    return data, nil
}

上限值应该来自接口契约，而不是照抄示例。若业务确实要处理大文件，就应采用流式写盘、校验哈希、超时和取消上下文，而不是把整个响应读进内存。

封装时要把策略写进函数名

我不建议做一个模糊的 closeResponse 工具函数，因为它隐藏了最重要的选择：是否完整消费。更清晰的方式是分别提供“读取小正文”“丢弃已知小正文”“直接关闭大正文”三种路径，并让调用方在状态码和接口契约处选择。这样代码评审时能直接看出，哪个分支追求复用，哪个分支优先保护资源。

同时，Client 与 Transport 本身也要复用。官方文档指出它们可安全地被多个 goroutine 并发使用，并且出于效率考虑应只创建一次。若每次请求都新建 Transport，即使 Body 处理完美，缓存连接也无法跨请求共享。

如何确认问题真的在响应体

排查时我会把“配置”和“行为”分开。先确认没有每次请求新建 Client 或 Transport，再记录实际协议版本、连接是否复用和新建连接次数。net/http/httptrace 的 GotConnInfo.Reused 可以直接告诉你某次请求拿到的连接是否复用：

trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        // 只记录复用事实，不在回调里执行耗时业务。
        log.Printf("连接复用=%t，空闲时长=%s", info.Reused, info.IdleTime)
    },
}

// 把追踪器放入本次请求的 Context，避免修改全局状态。
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
resp, err := client.Do(req)

如果 Reused 长期为 false，再对照代码检查：是否每次构造 Transport、是否服务端要求关闭连接、是否 Body 在某些分支未到 EOF、是否请求被超时或取消。不要只调高 MaxIdleConnsPerHost；如果连接从未回到空闲池，池容量再大也没有意义。

HTTP/2、重定向与超时的边界

本文的复用判断主要针对 HTTP/1.x keep-alive。HTTP/2 在一条连接上多路复用多个流，传输语义不同，但调用方仍必须关闭 Response.Body。代码可以用 resp.ProtoMajor 或日志确认实际协议，不要把 HTTP/1.x 的空闲 TCP 连接模型生搬到 HTTP/2 流上。

对于 Client.Do，官方文档还指出：发生错误时通常可以忽略 Response；非空 Response 与非空 error 同时出现，主要是 CheckRedirect 失败，此时返回的 Body 已关闭。正常收到 3xx、4xx、5xx 且 error 为 nil 时，仍按普通 Response 管理 Body。

超时或 Context 取消可能中断 Body 读取，这种情况下读不到 EOF 是失败结果的一部分，不能为了复用继续阻塞。应先保证请求有合理超时，再把连接复用当作性能优化，而不是正确性的前提。

常见问题

只调用 resp.Body.Close() 一定不能复用吗？

不能这样绝对判断。当前官方文档说明，Transport 在关闭 Body 时会在保守上限内尝试异步读到 EOF，因此小响应可能仍可复用。但如果业务明确希望 HTTP/1.x 连接稳定复用，完整消费到 EOF 再关闭更可控。

io.Copy(io.Discard, resp.Body) 应该放在 defer 里吗？

不建议把可能耗时的网络读取藏进 defer。先立即 defer resp.Body.Close() 保证释放，再在明确需要复用且响应大小可控的分支主动读取到 EOF，错误也能正常返回。

为什么把 MaxIdleConnsPerHost 调大仍没有改善？

该参数只影响可保留的每主机空闲连接数量。若 Body 未完整结束、服务端要求关闭、请求超时，连接根本不会成为可复用空闲连接，扩大池容量自然无效。

遇到超大错误响应应该排空吗？

通常不应无上限排空。先按接口契约设置读取上限，必要时只保留少量错误摘要并关闭 Body，接受该连接可能不复用。资源安全比节省一次 TCP 或 TLS 建连更重要。