Go HTTP 响应体读取后的关闭时机与连接复用

Go 的 HTTP 客户端拿到 *http.Response 时，响应头已经解析完成，但 resp.Body 通常仍代表连接上的响应数据。最小且可靠的规则是：不再需要响应体时关闭它；如果要让 HTTP/1 连接尽量复用，再根据响应体是否已经读到末尾决定是否值得有限排空。不要把“调用了 Close”理解成“已经完整读取”，也不要为了追求复用而无上限下载一个本来不需要的巨大响应。

官方资料：https://pkg.go.dev/net/http、https://go.dev/blog/http-connection-reuse

先区分响应头已到达与响应体尚未消费的状态

client.Do 返回成功后，状态码、响应头和响应体是不同层次的信息。只读取 StatusCode 并不会自动把 Body 读完；对于 HTTP/1，当前响应在字节流中的结束位置通常要由完整读取或响应边界信息确定，Transport 才有机会判断后面的连接能否继续服务下一次请求。

因此下面三个问题要分开回答：本次调用是否需要正文？如果需要，正文是否必须完整读取？如果只关心状态码，是否值得为复用而丢弃有限大小的剩余字节？HTTP/2 使用多路复用，未读 Body 对其他请求的影响与 HTTP/1 不同，但“拿到响应后负责关闭 Body”仍是客户端代码应保持的生命周期习惯。

完整读取时，把关闭动作绑定到成功拿到响应的位置

业务确实需要 JSON、文本或文件内容时，最简单的写法是拿到响应后立即 defer resp.Body.Close()，再使用读取器消费正文。这样即使后续解析返回错误，也不会因为某个分支忘记关闭 Body。关闭动作属于本次响应的生命周期，不应等到函数末尾某个“看起来一定会走到”的分支。

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "net/http"
)

type result struct {
    Name string `json:"name"`
}

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

    resp, err := client.Do(req)
    if err != nil {
        return result{}, err
    }
    // 成功拿到响应后立即登记关闭，解析失败也不会遗留 Body。
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        return result{}, fmt.Errorf("请求失败: %s", resp.Status)
    }

    var out result
    // Decoder 负责持续读取响应体，Close 负责结束本次响应生命周期。
    if err := json.NewDecoder(resp.Body).Decode(&out); err != nil {
        return result{}, err
    }
    return out, nil
}

这个例子没有把 Close 放在状态码判断之后，因为非 200 响应也可能携带需要释放的 Body。对 JSON 来说，解码器读到对象结束不一定等于底层响应已经读到 EOF；如果服务端在 JSON 后还有换行或其他可消费的尾部，是否能复用仍取决于 Transport 对剩余 Body 的处理。

只关心状态码时，直接关闭与有限排空怎么选

健康检查、探活或只判断写入是否接受的请求，可能完全不需要正文。此时不要把一个大错误页面、下载响应或未知长度的流全部读进内存。可以直接关闭，让 Transport 自己按当前 Go 版本的行为处理；如果项目需要兼容较早的 HTTP/1 行为，并且预计剩余响应很小，可以在关闭前做一个有上限的排空。

package clientutil

import (
    "io"
    "net/http"
)

func closeStatusOnly(resp *http.Response) {
    if resp == nil || resp.Body == nil {
        return
    }
    // 小响应可尝试有限排空，避免为未知大小的 Body 无限等待。
    _, _ = io.CopyN(io.Discard, resp.Body, 256

io.CopyN 到达 EOF 会返回读取错误，但这里的目标不是把错误页面解析成业务数据，而是把排空成本限制在 256 KiB。这个上限不是对所有服务都正确的固定数字：如果接口通常返回更大的可复用小正文，可以按业务响应大小调整；如果响应可能是大文件，则直接关闭往往比下载并丢弃剩余内容更划算。

把 Go 版本行为和 HTTP 版本放在一起理解

Go 官方关于 HTTP 连接复用的说明指出：在 Go 1.27 起，Transport 会对未读的 HTTP/1 响应体异步排空一段有限时间或有限字节，并在明确无法复用时跳过无效工作。对采用当前 Go 版本的普通调用，推荐保持简单：不需要 Body 时关闭它，把排空细节交给 net/http。如果维护旧版本运行时或需要精确控制旧行为，才考虑上面的有限排空辅助函数。

HTTP/1 的关键限制是同一连接上的响应按顺序占用字节流；HTTP/2 则把请求和响应拆成可复用的帧流，单个未读响应体不以同样方式阻塞其他请求。两者都不意味着可以省略 Close：关闭是释放响应资源和向 Transport 表达“本次响应结束处理”的明确动作。

另外，连接复用是 Transport 的内部策略，不要为每次请求都创建新的 http.Client。长期复用一个配置好的 Client，关闭每个 Response.Body，并让请求上下文携带期限与取消信号，通常比手工管理连接更稳定。

循环请求里的四个常见误区

• 只看状态码不关 Body：循环里会不断积累未释放响应，Transport 也无法正常管理连接。
• 每次循环都 new Client：失去了共享 Transport 和空闲连接池的机会。
• 无上限地 io.Copy(io.Discard, Body)：遇到大响应时，所谓“帮助复用”可能变成更高的下载成本。
• 把 Close 当作读取到 EOF：Close 结束生命周期，但不等价于调用者已经消费完整正文；是否复用要结合 HTTP 版本、响应边界和 Go 版本。

如果响应体需要交给另一个组件，先明确所有权：由读取组件负责完整消费和关闭，还是由调用方负责。不要在一个函数里关闭后又把 Body 返回给外层，也不要把关闭动作藏在无法说明责任边界的共享工具中。

发布前可以直接对照的速查表

最后可以用一句话记忆：先决定是否需要正文，再决定读多少；只要拿到响应，就为 Body 安排明确的关闭责任。连接复用是收益，不是让调用者无限排空响应的理由。

相关问题

resp.Body.Close 应该放在哪里？

在确认 client.Do 成功并拿到非空响应后立刻登记，通常就是 defer resp.Body.Close()。这样状态码判断、解析和其他提前返回路径都能覆盖。

只调用 Close 会不会复用 HTTP/1 连接？

不能把它当成绝对保证。连接是否复用还受响应是否读完、响应头、HTTP 版本和 Transport 行为影响；当前 Go 版本会对部分未读响应做有限异步排空，但代码仍应负责关闭。

为什么不建议总是把 Body 读完再关闭？

因为剩余内容可能很大。对于只关心状态码的请求，有限排空或直接关闭可能比下载并丢弃大量字节更合适。

官方资料（复制地址查看）：https://pkg.go.dev/net/http；Go 官方连接复用说明：https://go.dev/blog/http-connection-reuse；响应体接口说明：https://go.dev/src/net/http/response.go。