Go http.Response.Body 为什么必须关闭并尽量读完

Go 的 http.Response.Body 必须关闭，因为它不只是普通数据对象，而是客户端传输层交给调用方管理的流式资源。关闭意味着“我已经不再使用这个响应体”；读到 io.EOF 则意味着响应体已经完整消费。对默认 HTTP/1.x 传输而言，这两件事通常共同决定底层 keep-alive 连接能否顺利回到连接池。

最稳妥的规则是：拿到 resp 后立刻安排 defer resp.Body.Close()；业务本来就需要响应内容时，把它正常读完；业务不需要内容时，只对可控的小响应做有限排空；遇到大响应、取消或超时时及时关闭，不要为了复用一条连接而无限读取。

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

关闭和读完解决的不是同一个问题

“关闭”和“读完”经常被写成一句口诀，但它们承担的责任不同：

Go 当前的 net/http 文档还补充了一个容易被旧经验忽略的细节：多数情况下不需要为了连接复用手动无限排空，因为关闭 Body 时，传输实现会在一个保守上限内异步尝试读到完成。这个说明并没有取消调用方的关闭责任，也不等于“任何大小的响应都一定会被 Close 自动读完”。所以工程上更准确的说法是：必须关闭；业务需要的数据应正常读完；丢弃数据时要有限、可控地尽量读完。

Body 背后不只是一个 Reader

http.Client.Do 在响应头可用后就可以返回，响应体随后按需从网络读取。此时 resp.Body 虽然只暴露为 io.ReadCloser，背后却与传输协议、连接状态和 Transport 的连接池有关。默认客户端保证 Body 非空，即使服务器没有正文或正文长度为零，调用方也仍应按同一规则关闭它。

对 HTTP/1.x 来说，同一条 TCP 连接上的下一个响应必须从正确的字节边界开始。如果前一个 Body 还留着未读取内容，传输层不能把那条连接随便交给下一次请求。读到 EOF 提供了“本次响应已经结束”的明确信号；Close 提供了“调用方已经结束使用”的生命周期信号。

HTTP/2 使用多路复用，流与连接的关系不同，因此官方文档把“可能无法复用 keep-alive TCP 连接”的提醒明确写在 HTTP/1.x 场景下。不过这不意味着 HTTP/2 可以省略 Close：响应流仍然需要结束，资源所有权仍然要交还，取消和错误也仍要正确传播。

正常消费：先安排关闭，再有上限地读取

一个常见接口只返回几十 KB 的 JSON。最简单的写法是取得响应后立即 defer Close，然后给读取设置上限，避免服务端异常返回巨量内容。下面示例把“完整读取”和“资源关闭”放在同一个函数作用域内：

package api

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

type Result struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}

func fetchResult(client *http.Client, url string) (Result, error) {
    resp, err := client.Get(url)
    if err != nil {
        return Result{}, fmt.Errorf("发送请求失败: %w", err)
    }
    // 一旦拿到响应，就立刻安排关闭，避免后续分支漏掉资源释放。
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        // 错误响应也限制读取量，防止异常服务端返回过大的错误页。
        msg, readErr := io.ReadAll(io.LimitReader(resp.Body, 64

这里有一个边界：io.LimitReader 只负责“不超过上限”，并不能单独证明原始响应恰好在上限内。如果业务需要严格拒绝超大响应，可以把限制设为 max+1，读取后检查长度是否超过 max。这样既保护内存，也能在合法小响应上自然读到 EOF。

不需要正文：做有限排空，而不是无条件 ReadAll

健康检查、只看状态码的探测请求，往往不关心正文。如果服务端约定只返回很小的内容，可以在关闭前有限地复制到 io.Discard。这是一种“尽量读完”的策略：小响应通常会到 EOF，大响应达到上限后就停止，不会为了复用连接吞掉几百 MB 数据。

package api

import (
    "io"
    "net/http"
)

func closeWithBoundedDrain(resp *http.Response, maxDrain int64) error {
    // 只丢弃受控字节数；小响应可读到 EOF，大响应不会无限消耗带宽。
    _, copyErr := io.Copy(io.Discard, io.LimitReader(resp.Body, maxDrain))
    // 无论排空是否成功都要关闭，Close 才是必须完成的生命周期动作。
    closeErr := resp.Body.Close()
    if copyErr != nil {
        return copyErr
    }
    return closeErr
}

如果刚好读取了 maxDrain 字节，无法仅凭这个数字判断后面是否还有内容。因此这个函数的承诺不是“保证连接复用”，而是“在成本可控的前提下帮助小响应读完，然后始终关闭”。真正需要确认是否超限时，应再探测一个字节，或者根据可信的 Content-Length 和业务协议做判断。

大响应、超时和取消：及时停下比复用更重要

下载对象存储文件、读取持续流或遇到服务端异常大响应时，不应机械执行 io.ReadAll。连接复用是性能优化，不是必须压过带宽、内存和时延的目标。以下情况应优先停止读取并关闭：

• 调用方的 context.Context 已取消或超时；
• 响应状态、类型或长度已经表明内容不应继续处理；
• 下载校验失败，后续数据不再有业务价值；
• 响应是长连接或持续流，本来就不会在短时间内到达 EOF；
• 服务端没有可信长度，继续读取可能造成带宽或内存风险。

这时直接 Close 是正确选择。代价可能是当前 HTTP/1.x 连接不能复用，下一次请求需要新建连接；收益是应用及时停止无价值的网络读取。不要为了“连接池命中率”把资源保护做反了。

把处理责任放进固定函数边界

真正容易出错的不是某一行语法，而是响应体所有权在多层函数之间漂移。推荐给 HTTP 调用定义清楚的返回契约：

1. 如果函数返回解析后的业务对象，它就在内部读完或按上限读取并关闭 Body；
2. 如果函数返回 *http.Response 或 io.ReadCloser，文档必须明确由调用方关闭；
3. 同一个 Body 只指定一个关闭责任人，避免一层读取、另一层提前 Close；
4. 每个状态码分支都走到同一个关闭策略，错误分支不能成为泄漏入口；
5. Transport 和 Client 应长期复用，不要为了弥补 Body 管理问题频繁新建客户端。

可以把处理结果分成“完整消费”“有限消费”“提前终止”三类并记录指标。连接复用率下降时，先查未关闭、提前关闭和超大响应，而不是立刻调大连接池。这样故障处理会从猜测变成可定位的生命周期问题。

几个容易踩到的边界

Close 返回 nil，就代表已经读到 EOF 吗？

不代表。Close 表示关闭动作完成；是否读到 EOF 要看读取过程。当前默认传输可能在 Close 时于保守上限内继续处理剩余内容，但应用不应把它当作“任何响应都一定完整排空”的承诺。

为什么 defer 一定要写在 err 检查后？

请求失败时 resp 通常不可用。只有确认拿到了有效响应，才能访问 resp.Body 并安排关闭。把 defer 放在错误检查前可能触发空指针问题。

读到 EOF 还有别的价值吗？

有。响应的 Trailer 在 Body 读取返回 io.EOF 后才会填入最终值。需要校验 Trailer 的协议，必须把完整读取作为业务语义的一部分，而不只是连接池优化。

自动 gzip 解压会改变规则吗？

不会改变关闭责任。默认 Transport 可能透明解压响应，调用方读取的是解压后的 Body，但仍要关闭。读取错误也应向上返回，不能因为已经拿到部分数据就假装响应完整。

只调用 Close，不手动 drain，到底行不行？

对多数普通请求，当前官方文档明确说明通常不必手动把 Body 无限读完，因为 Close 会在保守限制内异步尝试完成。但当业务本来就要内容时，应正常读到 EOF；当明确丢弃小响应时，有限排空更可控；当响应很大或请求已取消时，直接关闭更合理。选择标准是响应规模与业务语义，而不是死记一条无条件口诀。

结论

http.Response.Body 的正确处理可以浓缩成三句话：Close 是必须履行的资源责任；读到 EOF 是完整消费和 HTTP/1.x 连接复用的重要信号；排空必须有成本边界。正常小响应读完再关，忽略的小响应有限排空再关，大响应或取消场景及时关并接受连接不复用。把这套规则固定在函数边界里，比在每个调用点临时补一个 defer 更可靠。