Go HTTP 响应体未关闭导致连接复用下降怎么办

如果 Go 程序反复调用 HTTP 接口，却发现连接数不断增加、请求延迟偶尔抬头，先检查每个 resp.Body 是否都在使用结束后关闭。HTTP 客户端先拿到响应头，正文仍然是按需读取的流；如果调用方既不读取也不关闭，HTTP/1 的 keep-alive 连接就可能无法被后续请求复用。

最小修复通常是：请求成功后立刻安排 defer resp.Body.Close()。如果确实需要正文，就读取正文并检查读取错误；不要把关闭责任交给垃圾回收，也不要在一个长循环里让大量 defer 等到外层函数才执行。

先确认 Response.Body 的责任边界

http.Client.Do 返回成功响应时，Response.Body 一定是非空的 io.ReadCloser。这表示响应头已经解析出来，但响应内容还要由调用方继续读取。官方文档明确要求调用方在用完后关闭它；如果正文没有读到结尾并且也没有关闭，底层 Transport 可能无法复用持久 TCP 连接。

这也是一个很容易被忽略的现场：业务只关心 StatusCode，看起来没有“数据要处理”，于是直接返回状态码。实际上，连接上的当前响应仍有自己的正文边界，调用方必须明确结束这段响应的资源责任。

只看状态码时，成功返回后立即关闭

只需要判断接口是否成功时，不必把正文读入内存，但仍然要关闭 Body。把请求封装在一个小函数里，可以让 defer 的生命周期与一次请求一致：

package main

import (
    "fmt"
    "net/http"
)

// fetchStatus 只关心状态码，但仍负责结束响应体的生命周期。
func fetchStatus(client *http.Client, url string) (int, error) {
    resp, err := client.Get(url)
    if err != nil {
        return 0, err
    }
    // 响应成功返回后立即登记关闭责任，避免 Body 遗留在连接上。
    defer resp.Body.Close()

    // 非 2xx 不一定会出现在 err 中，状态码要单独交给调用方判断。
    return resp.StatusCode, nil
}

func main() {
    status, err := fetchStatus(http.DefaultClient, "https://example.com/health")
    if err != nil {
        fmt.Println("请求失败:", err)
        return
    }
    fmt.Println("HTTP 状态码:", status)
}

这里的关键不是“必须把正文读完才算正确”，而是不能跳过关闭。当前版本的 net/http.Transport 会在关闭时尝试把未读正文异步读取到结尾，但这有保守上限，不能替代调用方的生命周期管理。

需要正文时，先读取再关闭并处理错误

如果业务要解析 JSON、读取文本或保存响应内容，就让读取操作显式出现在关闭之前。io.ReadAll 适合体积可控的响应；响应可能很大时，应改成流式解码或写入目标文件。

package main

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

// fetchBody 读取可控大小的响应，并把读取错误原样返回给上层。
func fetchBody(client *http.Client, url string) ([]byte, error) {
    resp, err := client.Get(url)
    if err != nil {
        return nil, err
    }
    // 无论后续读取成功还是失败，都要释放 Response.Body。
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, fmt.Errorf("读取响应正文失败: %w", err)
    }
    // 状态码和正文是两类信息，调用方可按业务决定是否接受非 2xx 正文。
    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("服务返回状态码 %d", resp.StatusCode)
    }
    return body, nil
}

ReadAll 返回错误时也不能提前跳过 Close。使用 defer 的好处是把这个清理动作绑定在函数返回路径上，包括读取失败和状态码不符合预期的分支。

循环请求不要让 defer 堆积到批量函数结束

下面这种写法虽然每次都调用了 Close，但 defer 会等整个 syncMany 返回才执行。如果循环次数很大，多个响应体会同时处于未关闭状态，排障时容易误判为连接泄漏：

// 不推荐：循环内的 defer 会堆积到 syncMany 返回。
func syncMany(client *http.Client, urls []string) error {
    for _, url := range urls {
        resp, err := client.Get(url)
        if err != nil {
            return err
        }
        defer resp.Body.Close()
    }
    return nil
}

更稳妥的做法是把一次请求拆成独立函数，让每轮函数返回时就执行清理：

// requestOne 让一次请求的 defer 与一次循环迭代绑定。
func requestOne(client *http.Client, url string) error {
    resp, err := client.Get(url)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    // 只需要确认请求完成时，读取少量正文即可；不要把大响应无界读入内存。
    if resp.StatusCode = 300 {
        return fmt.Errorf("%s 返回 %d", url, resp.StatusCode)
    }
    return nil
}

// syncMany 逐项调用 requestOne，确保每轮都及时释放 Body。
func syncMany(client *http.Client, urls []string) error {
    for _, url := range urls {
        if err := requestOne(client, url); err != nil {
            return err
        }
    }
    return nil
}

示例中的 fmt 需要和前一个代码片段一样导入；文章重点是生命周期，不是把多个片段拼成一个完整命令。生产代码还应给客户端设置合适的超时，并按业务决定是否继续处理后续 URL。

大响应、HTTP/1 和 HTTP/2 要分开判断

如果正文很大而业务只关心状态码，不建议无条件执行“把全部正文读完再丢弃”。下载和丢弃大正文可能比重新建立连接更慢。旧版本或自定义 Transport 场景可以采用有上限的读取策略，但还要同时处理时间上限、关闭时中断读取和 goroutine 生命周期，这套手写逻辑很容易出错。

当前 Go 官方对一般代码的建议是：不需要正文时关闭 Body，让 net/http 处理适度的异步读取；需要正文时正常读取并关闭。HTTP/2 通过多路复用传输多个流，某一个流的未读正文不会像 HTTP/1 的串行响应那样直接阻塞同一连接上的其他流，但这仍不代表可以忘记关闭 Body。

连接复用下降时，按三个证据点排查

遇到连接数异常或延迟变高时，可以按下面的顺序检查，重点是找出“哪一条请求路径忘了结束 Body”。

结论：把 Body 当作每次请求的必清资源

这类问题最有效的修复不是增加重试次数，而是先把响应体生命周期补完整：成功拿到响应后马上安排关闭；需要内容时读取并检查错误；批量请求用小函数隔离每次清理；遇到大响应和不同协议时再做有边界的取舍。这样既能保持代码简单，也能让 Transport 有机会复用 HTTP/1 的持久连接。

相关问题

• 只读取 StatusCode 还需要读取 Body 吗？通常不需要把正文全部读入内存，但必须关闭 Body。
• HTTP/2 下可以不关闭 Body 吗？不可以，关闭责任仍然在调用方；只是 HTTP/2 的多路复用减弱了 HTTP/1 的单流阻塞影响。
• 为什么循环里的 defer 看起来已经写了 Close 仍然占资源？因为 defer 绑定的是外层函数返回，不是当前循环迭代结束。
• 是否应该每次请求都创建新的 http.Client？通常不应该；复用 Client 和 Transport 更容易获得连接池收益。

参考资料：https://pkg.go.dev/net/http；https://go.dev/blog/http-connection-reuse。