Go net/http 请求体没有关闭会怎样影响连接复用

先说结论：如果你说的是客户端的 Request.Body，使用标准 http.Transport 时通常不用在调用方再次关闭，Transport 会负责关闭它；真正经常影响 HTTP/1.x 连接复用的是返回结果的 Response.Body。响应体既没有读完，也没有关闭，后续请求就可能拿不到原来的 keep-alive 连接。

先分清 Request.Body 和 Response.Body

一次客户端调用里至少有两个容易被叫作“请求体”的对象：Request.Body 属于发送方向，Response.Body 属于接收方向。前者把数据交给服务端，后者承载服务端返回的数据。它们的关闭责任不同，不能用同一条经验处理。

因此，看到连接数上升时，先查每个成功的 Do 是否关闭了 resp.Body，不要只盯着创建请求时传入的 reader。

标准 Transport 会替你关闭哪一部分

使用 http.Client.Do 或标准 Transport 发送请求时，非空的请求体会由底层 Transport 关闭，而且这个关闭可能在 Do 返回后异步发生。下面的写法把责任交给标准库，同时复用一个长期存在的 Client：

func postJSON(ctx context.Context, client *http.Client, url string, payload []byte) ([]byte, error) {
    // bytes.Reader 只负责提供请求数据，Transport 会关闭对应的 Request.Body。
    req, err := http.NewRequestWithContext(ctx, http.MethodPost, url, bytes.NewReader(payload))
    if err != nil {
        return nil, err
    }
    req.Header.Set("Content-Type", "application/json")

    resp, err := client.Do(req)
    if err != nil {
        // 请求失败时也不要假设自己还需要手动关闭标准 Request.Body。
        return nil, err
    }
    defer resp.Body.Close() // 响应体由调用方关闭，避免占住连接资源。

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }
    return body, nil
}

这里的关键不是“永远不要关闭 req.Body”，而是要分清调用层级：标准 Client/Transport 已经承担了这个责任；如果你自己实现了 RoundTripper，就必须遵守接口约定，在成功和失败路径都关闭请求体。

要让连接稳定复用，正确处理 Response.Body

响应体是流，Client.Do 返回时通常还没有被完整消费。最稳妥的习惯是：拿到响应后立刻安排 Close，需要内容就读到结束。标准文档说明，关闭时 Transport 会尝试在后台把响应体读到 EOF，但只会在保守的大小和时间范围内处理；主动读完更容易得到稳定结果。

func readResponse(resp *http.Response) ([]byte, error) {
    // 无论后面的读取成功还是失败，都要释放响应体。
    defer resp.Body.Close()

    // 读到 EOF 让 HTTP/1.x 的响应边界明确，Transport 才能判断连接是否可复用。
    return io.ReadAll(resp.Body)
}

这不等于每个响应都必须无条件把大文件读进内存。下载文件时可以用 io.Copy 写入目标流，或者按业务限制读取；核心仍是消费到合适的边界并关闭响应体。HTTP/2 使用多路复用 stream，未关闭响应体未必表现为“每次都新建 TCP 连接”，但仍可能占用流和客户端资源，所以关闭习惯不能省。

循环、重试和自定义 RoundTripper 的常见坑

第一，循环内不要这样写：把 defer resp.Body.Close() 放在一个很大的外层函数里，所有响应体会等循环结束才释放。把一次请求封装成小函数，或在本轮读取完成后显式关闭，资源边界会更清楚。

第二，不要为了“强制复用”把 req.Close 设成 true。这个字段会要求请求完成后关闭连接，效果正好与 keep-alive 相反。连接复用的前提是复用同一个 Client/Transport，并正确处理响应体，而不是手动操作连接开关。

第三，自定义 RoundTripper 要同时看成功和错误路径。接口约定要求它负责关闭请求体；如果把请求交给另一个 Transport，仍应确认代理层不会丢失这个责任。遇到“连接越来越多”的现象，可以按下面的顺序排查：是否遗漏 resp.Body.Close、是否提前返回、是否在循环里延迟关闭、是否主动设置了 req.Close、是否每次都新建 Transport。

常见问题

只调用 resp.Body.Close，不读取内容可以吗？

可以释放响应体，但如果响应还没读完，Transport 只能尝试有限度地排空；小响应更可能复用，大响应或耗时响应不应依赖这个行为。

请求失败时还需要手动关闭 req.Body 吗？

使用标准 Client/Transport 时，底层会关闭非空请求体，且可能异步执行。若是自定义 RoundTripper，则按自己的实现契约确保成功和失败都关闭。

关闭响应体后一定会复用原 TCP 连接吗？

不一定。服务端的 Connection 设置、协议版本、连接空闲策略、请求是否设置 Close 等都会影响结果。正确读取和关闭只是获得复用资格的必要习惯。