Go问答：net/http Request.Body请求结束后为什么仍有连接无法复用怎样完成一个可复用的最小示例

这个问题里最容易混淆的是两个同名的“Body”：发送请求时的 Request.Body，以及收到响应后的 Response.Body。对客户端连接复用来说，真正关键的是响应体是否被消费并关闭。请求体会由 Transport 负责关闭，但如果响应体还留着未读数据，HTTP/1.x 的 keep-alive 连接就可能不能回到复用池。

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

先把两个 Body 的责任分开

客户端请求的 Request.Body 是发送给服务端的输入流。对普通的 http.Client.Do 调用，底层 Transport 会负责关闭它；调用方通常不需要再围绕请求体做一套连接复用逻辑。相反，成功返回的 Response.Body 是从服务端流回来的输出流，调用方必须关闭它。

只写 defer resp.Body.Close() 已经比完全不关闭好，但它不等于“保证连接复用”。文档给出的条件是：响应体读到 EOF 并关闭后，底层 Transport 才更有机会把 HTTP/1.x 的持久连接留给下一次请求。Go 在关闭时会尝试在保守限制内异步读完，但把正文消费策略写清楚更可靠。

共享 Client 才有连接池可谈

连接池属于 Transport，而不是某次 Do 调用。推荐把 Client 放在长生命周期对象中，让多个请求共享同一个 Transport；Transport 本身支持并发使用。下面的配置只调高同一主机的空闲连接上限，不把每个请求都变成一条新连接。

var sharedClient = &http.Client{
    Transport: &http.Transport{
        // 连接池只服务于复用策略，数值应按并发和服务端限制调整。
        MaxIdleConnsPerHost: 8,
    },
    Timeout: 10 * time.Second,
}

如果每次调用都写 http.Client{Transport: &http.Transport{...}}，即使每个响应都关闭了，之前的连接池也无法被新的 Transport 使用。另一个常见误区是把 Transport.CloseIdleConnections 当作日常清理手段；它适合生命周期切换或主动收缩空闲连接，不适合每个请求结束时调用。

小响应的可复用最小示例

下面的函数发送一个 JSON 请求，并在检查状态前把一个预期较小的响应体读完。示例用 io.Copy 丢弃响应正文，只适合响应大小已知或受业务约束的场景；如果响应可能很大，应改成流式解析，而不是无界丢弃。

package main

import (
    "bytes"
    "context"
    "fmt"
    "io"
    "net/http"
    "time"
)

var client = &http.Client{
    // 一个 Client 长期复用，底层 Transport 才能保留空闲连接。
    Timeout: 10 * time.Second,
}

func postAndReuse(ctx context.Context, endpoint string, payload []byte) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, bytes.NewReader(payload))
    if err != nil {
        return fmt.Errorf("创建请求失败: %w", err)
    }
    req.Header.Set("Content-Type", "application/json")

    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("发送请求失败: %w", err)
    }
    defer resp.Body.Close()

    // 小响应先读到 EOF，给 Transport 回收 HTTP/1.x 连接的机会。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return fmt.Errorf("读取响应失败: %w", err)
    }
    if resp.StatusCode = 300 {
        return fmt.Errorf("服务端返回状态码 %s", resp.Status)
    }
    return nil
}

这里的关键顺序是“拿到响应后立刻安排关闭，随后消费正文”。如果只读取响应头就返回，连接是否能复用取决于 Transport 能否在限制内补读；如果响应正文很大，补读成本可能超过新建连接的成本，业务应明确选择流式处理、限制大小或放弃复用。

仍然不能复用时检查这些边界

还要区分 HTTP/1.x 和 HTTP/2：本文讨论的“读完响应体后回到空闲连接池”主要对应 HTTP/1.x 的持久 TCP 连接；HTTP/2 在一条连接上复用多个流，观察指标和复用行为不同。连接复用也不是业务正确性的替代品，状态码、响应头和正文格式仍需要按接口协议处理。

相关问题

请求结束后还需要手动关闭 Request.Body 吗

对交给 http.Client 发送的客户端请求，Transport 负责关闭请求体。更值得确保的是对成功响应调用方负责的 Response.Body。

只调用 Response.Body.Close 不读正文可以吗

可以结束资源生命周期，但未读完的响应体可能让 HTTP/1.x 连接无法复用。小响应尽量读到 EOF；大响应按业务方式流式处理。

为什么共享 Client 仍然看不到复用

检查服务端是否主动关闭连接、请求是否设置了 Close、Transport 是否禁用 keep-alive，以及是否实际使用了 HTTP/2。不要只看 Client 对象是否是全局变量。