Go问答：net/http Request.Body请求结束后为什么仍有连接无法复用为什么结果为空或不符合预期

如果你在 Go 客户端里调用了 Request.Body.Close()，但下一次请求仍然没有复用连接，先不要把问题归咎于这个 Close。客户端的请求体和响应体是两个生命周期：前者负责上传，后者决定响应连接能否被继续使用。

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

本篇只讨论 net/http 中“请求结束后连接仍无法复用”的排查边界。结论是：客户端 Request.Body 由 Transport 负责关闭；客户端必须关闭 Response.Body，而 HTTP/1.x 下响应体没有读完时，Transport 可能放弃复用连接。

先区分 Request.Body 和 Response.Body

Request.Body 是发给服务端的数据，例如 POST 的 JSON 或上传文件。客户端请求中，它由底层 Transport 负责调用 Close；如果是服务端 Handler 收到的 r.Body，则由 Server 负责关闭，Handler 不需要重复关闭。

真正容易漏掉的是 resp.Body。它是客户端读取服务端返回内容的流，必须由调用方关闭。可以把职责先记成这张表：

连接复用真正看响应体是否收尾

对默认 Transport 来说，连接复用首先受响应体影响。最小安全写法是先判断错误，再立刻延迟关闭响应体；如果业务不需要响应内容，就把它读到末尾，让 Transport 有机会复用 HTTP/1.x 的 keep-alive 连接。

package main

import (
    "io"
    "net/http"
)

func doRequest(client *http.Client, req *http.Request) error {
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    // 响应体由调用方关闭，避免连接和文件描述符长期占用。
    defer resp.Body.Close()

    // 不需要正文时读完它，给 HTTP/1.x Transport 复用连接的机会。
    _, err = io.Copy(io.Discard, resp.Body)
    if err != nil {
        return err
    }
    return nil
}

如果业务需要正文，可以把 io.Copy 换成 io.ReadAll 或解码器。不要为了“读完”而无限制地把不可信响应全部放进内存；大响应应使用流式处理，或先用 io.LimitReader 设上限。

请求体 Close 仍然要写，但它不是复用开关

当请求体来自文件、管道或自定义 Reader 时，资源本身仍然要按自己的生命周期关闭。例如文件由创建它的代码负责关闭，http.Transport 只负责在发送请求后关闭作为 Request.Body 暴露出去的读取器。将两个 Close 混在一起，容易误判。

func upload(client *http.Client, file *os.File) error {
    req, err := http.NewRequest(http.MethodPost, "https://example.com/upload", file)
    if err != nil {
        return err
    }
    // 文件由本函数打开，因此由本函数负责关闭；不要把责任推给 Transport。
    defer file.Close()

    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    // 响应体关闭与请求体关闭是两件事，分别处理。
    defer resp.Body.Close()
    _, err = io.Copy(io.Discard, resp.Body)
    return err
}

上例的核心不是“多写一个 Close”，而是明确资源所有者：文件由打开它的代码管理，响应体由发起请求的调用方管理，请求体的最终关闭由 Transport 执行。

仍然无法复用时按四层排查

第一层看响应体：是否在判断状态码前就返回，是否只读了一部分，是否遗漏了 defer resp.Body.Close()。第二层看请求字段：客户端请求把 Request.Close 设为 true 会禁止请求之间复用 TCP 连接。

第三层看 Transport：DisableKeepAlives 会关闭 HTTP keep-alive；如果每次请求都新建 Transport，也会失去原有的空闲连接池，应复用同一个 http.Client 或 Transport。第四层看协议：文档中的“未读完响应体导致不复用”主要针对 HTTP/1.x，HTTP/2 的复用模型不同，但响应体仍然必须关闭。

因此，看到“Request.Body 已经 Close 但连接没复用”时，优先把检查点移到响应体和 Transport，而不是继续重复关闭同一个请求体。

最后记住这份清单

• 客户端 Request.Body 的关闭由 Transport 负责，外部文件等资源仍按所有权关闭。
• 客户端 Response.Body 必须关闭，HTTP/1.x 尽量读到 EOF。
• 不要设置 Request.Close 或 DisableKeepAlives，除非确实需要。
• 复用长期连接时复用同一个 Client/Transport，不要每次请求都新建。

常见问题

只调用 resp.Body.Close，不读正文可以吗？

可以作为基本资源清理；当前 Transport 会在关闭时尝试异步读完一部分正文，但为了让复用更可预测，小响应建议主动读完，大响应采用有上限的流式处理。

服务端 Handler 要不要关闭 r.Body？

通常不需要，Server 会关闭服务端请求体。Handler 应专注于按需读取，并在写响应前尽可能完成需要的请求体读取。