Go net/http 响应体未完全读取时关闭连接复用异常怎么办

我在排查 Go 客户端“明明调用了 Close，后面的请求却没有稳定复用连接”时，最容易忽略的是：关闭响应体不等于已经读完响应体。net/http 文档明确要求调用方关闭 resp.Body；如果响应体既没有读到 EOF，又没有关闭，底层 Transport 可能无法复用 HTTP/1.x 的持久连接。正确做法是先注册关闭，再根据业务决定是否主动消费剩余内容。

先分清“关闭”与“读完”

Client.Do 返回成功时，resp.Body 一定非空，它是按需读取的流。调用 Close 可以释放调用方持有的响应体，但当内容还没有到 EOF 时，Transport 是否继续把它读完、是否能保留底层连接，要受响应大小和协议实现影响。Go 1.27.3 的文档还特别说明，关闭 Body 后 Transport 会在保守上限内异步尝试读到 EOF，所以很多小响应不需要手动再读一遍。

因此，“复用异常”通常要同时检查三点：是否每个成功响应都关闭了 Body；是否在关闭前提前返回；是否把每次请求都绑定到新建的 Transport。最后一种情况即使 Body 处理正确，也不会得到稳定的连接池效果。

常规请求的安全写法

resp, err := client.Do(req)
if err != nil {
    return err // 请求未得到可用响应时，不能读取 resp.Body
}
defer resp.Body.Close() // 先登记释放动作，覆盖后续 return 分支

if resp.StatusCode = 300 {
    _, _ = io.Copy(io.Discard, resp.Body) // 小型错误响应可读完，帮助连接回池
    return fmt.Errorf("unexpected status: %s", resp.Status)
}

data, err := io.ReadAll(resp.Body) // 需要正文时一直读取到 EOF
if err != nil {
    return fmt.Errorf("read response body: %w", err) // 保留网络读取错误
}
return useData(data)

这里的关键不是把 Close 写成模板，而是让它尽早进入函数的退出路径。io.ReadAll 适合内容有明确上限的接口；如果接口可能返回任意大正文，应先用 io.LimitReader 或流式处理，避免为了复用连接把整份内容堆进内存。

只看状态码时，是否需要主动读完

如果业务只关心 StatusCode、Header 或重定向结果，仍然必须关闭 Body。对很小的响应，可以在关闭前把剩余内容丢弃：

func checkOnly(client *http.Client, req *http.Request) error {
    resp, err := client.Do(req)
    if err != nil {
        return err // 先处理请求错误，再接触响应体
    }
    defer resp.Body.Close() // 无论状态码如何都释放响应体

    _, copyErr := io.Copy(io.Discard, resp.Body) // 消费剩余字节，便于 HTTP/1.x 复用
    if copyErr != nil {
        return fmt.Errorf("discard response: %w", copyErr) // 读取失败不能伪装成成功
    }
    if resp.StatusCode != http.StatusNoContent {
        return fmt.Errorf("status=%d", resp.StatusCode) // 示例只接受 204
    }
    return nil
}

不过，主动读完不是永远正确：下载接口、长轮询、SSE 或很大的错误页都不适合无界丢弃。此时应设置请求上下文和大小边界，读到业务停止点后关闭，并接受该次 HTTP/1.x 连接可能不能复用。

用协议和 Transport 排除误判

默认 Transport 的连接池是复用的，但它必须是长期存在的共享对象。不要在循环里反复创建 &http.Transport{} 或 http.Client{Transport: ...}。同时，HTTP/2 的复用模型不是 HTTP/1.x 的单条 TCP 请求串行复用；服务端也可能通过 Connection: close 主动结束连接。换句话说，观察到“连接数上升”只能说明现象，还不能直接证明是漏了 Close。

复查时固定一个 Client 连续发送请求，记录响应协议、Body 读取错误、服务端关闭标记和 Transport 配置。若小响应已完整读取且正确关闭，仍不能复用，再检查是否更换了 Transport、是否走了代理、服务端是否主动关闭，以及是否其实已经切到 HTTP/2。

最后按这张清单收口

• err == nil 后是否立即登记了 resp.Body.Close？
• 需要正文时是否处理了读取错误，并确认读取目标有大小边界？
• 只看状态码时，是否对小响应消费剩余内容，而不是对大流响应无界读取？
• 是否复用了同一个 Client/Transport，并区分了 HTTP/1.x 和 HTTP/2？

常见追问

只调用 Close 能保证下一次请求复用吗？

不能保证。它是必要的资源释放动作，但未读完的响应体、协议版本、服务端关闭策略和 Transport 生命周期都会影响最终结果。

为了复用连接，所有响应都应该 io.ReadAll 吗？

不应该。对大响应强行读入内存会制造更大的问题；应按内容大小、流式语义和取消策略决定是否消费到 EOF。