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

Go HTTP 请求 Body 不关闭为什么连接池复用变差

来源：17golang原创 2026-09-07 07:42:02 0浏览收藏

Go 的 HTTP 客户端里，Response.Body 不是普通返回值，而是一段仍占用响应资源的流。请求成功后如果既不读完也不关闭它，Transport 可能无法把底层持久连接放回空闲池；如果每次请求都新建 http.Client，即使关闭正确，也没有稳定的连接池可以复用。

最稳妥的做法是复用一个长期存活的 http.Client，在确认 err == nil 后立即为 resp.Body 安排 defer Close；需要保留 HTTP/1 连接时，再根据响应大小读到 EOF 或主动丢弃剩余内容。

要点速览

Do 成功返回后，调用方负责关闭非空的 resp.Body。
关闭是资源底线，读到 EOF 更有利于 HTTP/1 持久连接回池。
Client 和它的 Transport 应跨请求复用，不要在循环里反复创建。

先看清 Response.Body 的连接复用边界

http.Client.Do 返回的 Response 只是响应外壳，真正承载网络内容的是 Response.Body。底层 Transport 维护连接缓存，客户端下一次请求能否复用 TCP 连接，取决于前一个响应的资源是否已经妥善结束。

Go http.Client、Transport、Response.Body 与 TCP keep-alive 的连接复用边界关系图 — 图1：Response.Body 位于响应资源边界内，Transport 才持有可复用的连接缓存。

因此，下面这种写法的问题不是“少了一行清理代码”这么简单：它会把响应体留在未完成状态，连接可能不能回到空闲连接池。

resp, err := client.Do(req)
if err != nil {
    return err
}
// 这里只取状态码，却遗漏了 Body.Close，响应资源没有明确结束。
return checkStatus(resp.StatusCode)

错误判断要放在前面。发生错误时不能假定 resp 可用；成功后则应立刻建立 Body 的关闭责任。

正确关闭 Body 还要区分读取策略

只调用 Close 能避免资源长期泄漏，但它不等价于“已经读完响应”。对 HTTP/1 请求，未读完的响应内容可能阻止连接复用；小响应通常直接读入内存，大响应或无需保存正文时，可以把剩余内容丢弃后关闭。

Go Response.Body 的 io.ReadAll、io.Copy 丢弃、Close 与 HTTP 持久连接关系图 — 图2：读取策略和 Close 共同决定响应资源如何离开当前函数，协议层分别维护连接或流。

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

    resp, err := client.Do(req)
    if err != nil {
        return "", err
    }
    // 成功响应的 Body 由当前函数负责关闭，避免调用方忘记清理。
    defer resp.Body.Close()

    // 小响应需要正文，因此读到 EOF 后再交给上层解析。
    data, err := io.ReadAll(resp.Body)
    if err != nil {
        return "", err
    }
    if resp.StatusCode = http.StatusMultipleChoices {
        return "", fmt.Errorf("unexpected status: %s", resp.Status)
    }
    return string(data), nil
}

若只关心状态码，可以不把全文放进内存，但应明确采用“丢弃剩余内容”的策略：

func probe(ctx context.Context, client *http.Client, url string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodHead, url, nil)
    if err != nil {
        return err
    }
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    // 不需要正文时释放剩余字节，再关闭响应体。
    _, _ = io.Copy(io.Discard, resp.Body)
    return resp.Body.Close()
}

大响应不宜无上限地读取。可以用 io.LimitReader 只取需要的前缀，超过上限时记录“截断”状态；但如果目标是尽量复用 HTTP/1 连接，就要结合响应体大小和带宽成本决定是否继续丢弃。

复用 Client，别让连接池每次重新出生

http.Client 和 Transport 都可以并发使用，适合在服务对象、包级依赖或应用初始化阶段创建一次。循环里写 &http.Client{} 会不断产生新的 Transport 状态，表现出来就像连接池复用变差。

现象	常见原因	先检查什么
请求越来越慢	Body 未关闭或连接无法回池	`Do` 成功后的关闭位置
连接数持续上升	每次创建 Client，或响应体长期存活	Client/Transport 的生命周期
内存随大响应增长	无界 `io.ReadAll`	是否需要限制读取大小

type API struct {
    client *http.Client
}

func NewAPI() *API {
    // 一个 API 实例复用同一个 Transport，连接缓存才有机会跨请求生效。
    return &API{client: &http.Client{Timeout: 8 * time.Second}}
}

不要为了“修复连接泄漏”把 DisableKeepAlives 全局打开。它会改变连接复用策略，可能掩盖 Body 生命周期问题，并增加握手成本。只有明确不需要持久连接时，才把它作为单独的设计决策。