当前位置：首页 > 文章列表 > Golang > Go问答 > Go HTTP 请求后连接复用变差是不是 Body 没关闭

Go HTTP 请求后连接复用变差是不是 Body 没关闭

来源：17golang原创 2026-11-14 14:55:47 0浏览收藏

很多使用Go开发的朋友经常碰到这类场景：批量发了一段时间HTTP请求之后，连接复用效果突然变得很差，大量新TCP连接被创建，第一反应往往是是不是请求返回的Body没关闭？这个问题确实是非常高频的诱因，但连接复用变差的原因并不止这一个，不少其他容易忽略的细节也会导致连接无法正常放回连接池被复用。

没关闭Response Body是导致Go HTTP连接复用变差的最常见原因，但不是唯一原因，请求响应Header配置、自定义Transport参数、错误处理逻辑不当等多种情况都会破坏连接复用逻辑，需要结合具体现场日志逐点排查。

是，但更准确的说法是：Go HTTP 客户端如果没有正确处理 Response.Body，确实可能让后续请求的连接复用变差。仅仅调用 Close 也不代表所有场景都一定复用，尤其要区分“是否读到响应体末尾”和“是否释放 Body”这两个动作。

生产代码的安全基线是：请求成功后立即安排 defer resp.Body.Close()；如果本次响应内容不需要保留，就把响应体读到 EOF 再关闭。下面只讨论响应体生命周期、HTTP/1.x 与 HTTP/2 的连接条件，不把它扩展成压测结论。

响应体为什么要读完并关闭

http.Client.Do 成功返回时，Response.Body 一定是非空的，调用方负责关闭它。Go 官方文档给出的关键条件是：如果 Body 没有读到 EOF 并关闭，底层 Transport 可能无法复用持久 TCP 连接。

这里有两个独立责任：

读到 EOF：让 HTTP 客户端知道当前响应的边界已经结束，连接上的后续字节才有机会被解释为下一次响应。
调用 Close：释放响应体相关资源，即使读取过程中发生错误，也要保证清理动作执行。

Response Body、EOF、Close、Transport 与持久 TCP 连接之间的静态关系 — 图1：Go HTTP 响应体生命周期与连接复用条件的结构说明图，不是截图或运行证据。

只看状态码时，怎样处理 Body

如果业务只关心状态码，最小的生产写法不是直接返回，而是先消费响应体。这样做的代价是需要读取服务端已经发来的内容；如果服务端返回体非常大，应从接口设计上减少无用响应，而不是默默把大响应留在连接上。

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

    resp, err := client.Do(req)
    if err != nil {
        return 0, err
    }
    // 无论后续读取是否成功，都要释放响应体资源。
    defer resp.Body.Close()

    // 只看状态码也先读到 EOF，给 Transport 判断响应边界的机会。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return 0, fmt.Errorf("discard response body: %w", err)
    }
    return resp.StatusCode, nil
}

这段代码的重点不是“所有响应都必须复制到内存”，而是使用 io.Copy 流式消费，不把 Body 转成字符串或字节切片。若业务确实需要 JSON，就直接让解码器从 resp.Body 读取，并同样保留 defer resp.Body.Close()。

Close 了，为什么连接仍可能没有复用

很多旧代码只有这一句：defer resp.Body.Close()。它解决了资源释放，却不等价于“已经读完响应体”。Go 的 Transport 在关闭 Body 时会尝试把剩余内容读到 EOF，但这个动作有保守的上限；如果未读内容仍然存在，连接可能被放弃，下一次请求就要建立新连接。

因此判断代码时可以按下面的优先级看：

代码行为	连接复用判断	处理建议
没有 Close	资源泄漏或连接状态异常风险高	成功返回后立即 defer Close
Close，但没有消费 Body	小响应可能被尝试排空，大响应或截断响应不保证复用	需要复用时主动读到 EOF
读到 EOF 并 Close	最符合 HTTP/1.x 持久连接的安全基线	保持这个模式，再排查 Transport 其它配置
请求本身失败	通常没有可用 Response，不要访问 nil Body	先处理 error，再处理非空 Response

HTTP/1.x 和 HTTP/2 不要混为一谈

HTTP/1.x 在一条连接上按顺序承载响应。客户端只有读完当前响应，才能准确找到下一条响应的起点，所以未读 Body 很容易直接影响连接复用。HTTP/2 则把响应拆成可独立管理的流，多路复用让一个未读流通常不会像 HTTP/1.x 那样阻塞其它流。

这不是“HTTP/2 就可以不 Close”。关闭 Body 仍然是调用方责任，Transport 也仍然需要回收流和资源。正确的工程判断是：协议差异解释了症状为什么不同，但不能替代响应体生命周期管理。

HTTP/1.x、HTTP/2、响应流、未读 Body 与 Transport 连接复用边界 — 图2：HTTP/1.x 与 HTTP/2 连接复用边界的结构说明图，不是截图或运行证据。

生产排障时按四个方向复查

搜 Body 生命周期：检查每个成功的 Do、Get 或封装客户端调用，确认 Body 没有被提前丢弃，也没有只在部分分支关闭。
看读取边界：只拿状态码的调用是否消费了响应体；解码失败时是否仍然执行 Close；是否因为读取上限故意留下未读内容。
确认协议：不要拿 HTTP/2 的多路复用经验推断 HTTP/1.x；同时检查自定义 Transport、代理和 TLS 设置是否改变了协议选择。
再看连接指标：在不把示例代码当作运行证据的前提下，用客户端自己的连接统计、服务端访问日志和受控压测确认新建连接是否异常增加。

结论可以压缩成一句话：Body 不关闭是明显错误，Body 只关闭不读取也可能牺牲复用；需要稳定复用时，优先读到 EOF，再关闭 Body。如果已经做到这一点，仍然频繁新建连接，就继续检查响应是否被截断、Transport 是否被重复创建，以及实际请求是否走了 HTTP/1.x 或 HTTP/2。