Go HTTP 请求结束后连接未复用的 Body 处理

Go 的 HTTP 客户端出现“请求结束后连接没有复用”时，先看 resp.Body，不要只盯着 Transport 参数。对客户端响应来说，Body 由调用方关闭；如果响应体既没有读到结束位置，也没有关闭，底层 Transport 就可能无法复用 HTTP/1.x 的持久连接。

实际处理可以按业务拆成三类：需要完整正文就读取到 EOF 后关闭；只需要判断头部或读取有限内容，就明确设置上限并关闭；完全不需要正文，也至少关闭 Body，并接受连接复用可能受响应体剩余内容影响的事实。

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

连接复用依赖读取与关闭

http.Client 通常通过 Transport 管理连接。Do 返回的 Response 即使正文长度为零，也会带有非空的 Body；这意味着“没有正文”不等于“可以不处理 Body”。

最小的完整读取写法如下。defer 要紧跟在错误判断之后，这样后续任何提前返回都会执行关闭；而 io.ReadAll 负责把响应体消费到结束位置。

resp, err := client.Do(req)
if err != nil {
    // 请求没有拿到可用响应，不能访问 resp.Body。
    return err
}
defer resp.Body.Close()

body, err := io.ReadAll(resp.Body)
if err != nil {
    // 读取失败仍然保留错误，Close 由 defer 负责执行。
    return err
}
_ = body // 这里继续解析正文，示例只关注 Body 生命周期。

如果代码只写了 defer resp.Body.Close()，通常可以避免资源长期占用，但不能把它理解为“无条件保证连接复用”。Go 文档说明 Transport 在关闭 Body 时会在保守上限内异步尝试读完响应体；对于需要稳定复用的普通小响应，显式消费到 EOF 更容易让意图清楚。

按响应体大小选择读取方式

读取策略要由业务结果决定，而不是为了复用连接盲目把所有正文装进内存。小型 JSON、状态文本适合完整读取；正文可能很大，或者只允许接收有限字节时，应采用受限读取并把“超限”当成业务判断。

例如，接口只允许读取最多 1 MiB 的文本，可以把上限放在读取器上，并额外读取一个字节判断是否超限：

const maxBody = 1  maxBody {
    // 多读出的一个字节只用于确认超限，不把超大正文交给解析器。
    return fmt.Errorf("response body exceeds %d bytes", maxBody)
}
return parse(body)

这里的关键是：io.LimitReader 只限制本次读取器看到的字节数，它不会自动替你完成整个底层 resp.Body 的消费。确认超限后仍然要执行 Close；如果业务必须尽量复用 HTTP/1.x 连接，就不要把受限读取误当成完整消费。

把关闭动作放在请求分支内

最常见的遗漏发生在循环和多分支代码中：某个状态码提前返回、解析失败直接跳出，或者把关闭动作写到了循环外。应该让每次拿到响应后都立刻绑定它自己的清理逻辑。

for _, endpoint := range endpoints {
    resp, err := client.Get(endpoint)
    if err != nil {
        // 单个地址失败时记录并继续，不能使用不存在的 resp。
        continue
    }

    func() {
        defer resp.Body.Close() // 用局部函数让 defer 每轮请求结束就执行。
        if resp.StatusCode != http.StatusOK {
            // 非成功状态也要关闭 Body，避免错误分支留下响应体。
            return
        }
        data, err := io.ReadAll(resp.Body)
        if err != nil {
            // 读取错误只影响当前响应，不改变清理责任。
            return
        }
        consume(data)
    }()
}

局部函数不是为了追求形式，而是为了缩短 defer 的生命周期。如果直接在大循环里累积 defer，关闭动作可能一直等到整个函数结束；当请求数量较多时，响应体和连接状态就会同时堆积。

大响应体不要用一次性读取掩盖边界

io.ReadAll 适合大小有上限且可以接受一次性分配的正文。下载、导出或流式接口则应把 resp.Body 交给文件、解码器或分块处理逻辑，并仍然在所有返回路径上关闭它。

resp, err := client.Do(req)
if err != nil {
    // 只有 err 为 nil 时才开始处理响应体。
    return err
}
defer resp.Body.Close()

dst, err := os.Create("result.data")
if err != nil {
    // 文件创建失败时仍由 defer 关闭网络响应体。
    return err
}
defer dst.Close() // 文件和网络 Body 各自拥有独立的关闭责任。

if _, err := io.Copy(dst, resp.Body); err != nil {
    // Copy 负责持续消费正文，失败时把真实错误返回给上层。
    return err
}
return nil

这种写法的目标是控制内存，而不是跳过 Body。只要业务需要完整接收内容，就应让读取操作持续到 EOF；如果业务允许提前终止，则要明确这是“主动放弃剩余响应体”，后续连接是否复用应交给 Transport 的实际策略，而不能在代码里假定一定复用。

用 Transport 配置辅助排查

当 Body 处理已经清楚，才检查 Transport。客户端和 Transport 应尽量复用，而不是每个请求新建一个；Transport 默认会缓存连接，但空闲连接数量、空闲超时以及是否禁用 keep-alive 都会影响观察结果。

transport := &http.Transport{
    MaxIdleConns:        20,              // 控制整个 Transport 保留的空闲连接数。
    MaxIdleConnsPerHost: 5,               // 控制同一主机的空闲连接数。
    IdleConnTimeout:     30 * time.Second, // 长时间空闲后主动释放连接。
}
client := &http.Client{Transport: transport}

// client 应在多个请求之间复用，避免每次请求重新创建 Transport。
_ = client

不要先把 DisableKeepAlives 打开来“修复”复用异常：它会直接阻止请求之间复用 TCP 连接，只适合明确的隔离场景。排查时可以按以下顺序判断：

• 每个成功响应是否都在错误判断后关闭了 Body。
• 需要完整正文的分支是否确实读到了 EOF，而不是只读了前几个字节。
• 循环中的 defer 是否绑定在局部函数内，避免延迟到整个批处理结束。
• 是否错误地为每个请求创建新的 Client 或 Transport。
• Transport 是否配置了 DisableKeepAlives、过短的 IdleConnTimeout 或过小的空闲连接上限。

最后记住这三个判断

第一，Close 是调用方对响应体的基本责任；第二，连接复用和正文是否完整消费有关，不能只看有没有调用 Close；第三，响应体上限解决的是内存与业务输入边界，不自动等于已经读完网络响应。

如果只是偶发复用不足，先从 Body 生命周期和循环提前返回查起；如果所有请求都不复用，再检查 Client、Transport 是否被重复创建或显式禁用了 keep-alive。把这两层分开，通常比不断调大连接池更快找到原因。

相关问题

只调用 resp.Body.Close 不读取正文可以吗？ 可以释放调用方责任，但如果希望稳定复用 HTTP/1.x 连接，通常应在业务允许时读到 EOF；Go Transport 关闭时会尝试在保守上限内异步消费。

io.LimitReader 会自动关闭 Body 吗？ 不会。它只是限制读取器，原始 resp.Body 仍然必须由调用方关闭。

为什么循环里 defer Close 容易出问题？ 函数级 defer 会等外层函数返回才执行，批量请求多时会让多个响应体同时存活；用局部函数包住每次请求即可缩短生命周期。