net/http Transport 如何复用连接并正确关闭响应体

想让 Go 的 HTTP 请求复用连接，核心不是手动“打开”某个开关，而是同时做好两件事：复用同一个 http.Client（以及它持有的 Transport），并在拿到响应后及时关闭 Response.Body。如果还要让 HTTP/1 连接尽量回到空闲池，读取到响应体末尾通常比只调用 Close 更稳妥；当前 Go 1.27 已对部分未读响应体提供有限的异步 drain，但关闭响应体仍然是调用方的责任。

下面只讨论响应体生命周期与连接复用，不涉及代理认证。先记住一个判断：响应头已经返回，不代表这条连接已经可以交给下一次请求使用，因为响应体仍然占着字节流的当前位置。

为什么 Response.Body 关闭会影响复用

http.Client.Do 返回的 Response 中，状态码和响应头已经解析完成，但 Response.Body 仍是一个可读流。HTTP/1 的多个响应通常在同一条连接上连续排列，Transport 必须知道当前响应体已经结束，才能把后续字节解释成下一次响应。

因此，下面这段最小写法无论成功还是后续处理失败，都应该保留：

func fetchStatus(client *http.Client, url string) (int, error) {
    // Do 返回非空响应后，调用方负责关闭响应体。
    resp, err := client.Get(url)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close()

    // 这里只需要状态码；不把正文当成业务数据读取。
    return resp.StatusCode, nil
}

只关闭而不读取正文，并不等于旧版本下每次都能复用 HTTP/1 连接。正文很小、连接协议和 Go 版本合适时，Transport 可能可以处理；但如果正文仍有较多字节，连接可能被放弃。对调用方来说，Close 是资源生命周期要求，是否复用还取决于正文是否读完、服务器是否允许 keep-alive 以及协议实现。

先复用 Client，再谈 Transport 的连接池

不要在每次请求里写 &http.Client{}，也不要每次都创建一个新的 http.Transport。客户端和 Transport 应该在应用生命周期内复用，让 Transport 有机会维护连接池：

var httpClient = &http.Client{
    Transport: &http.Transport{
        // 连接空闲一段时间后回收，避免长期占用无用连接。
        IdleConnTimeout: 90 * time.Second,
        // 同一主机允许保留的空闲连接数量，按业务并发量调整。
        MaxIdleConnsPerHost: 8,
    },
    // 限制一次请求的总耗时，避免调用方长期占住响应体。
    Timeout: 10 * time.Second,
}

这里的参数只是在连接池已有复用机会时做容量和生命周期管理，不能替代 Body.Close。如果自定义 Transport，还要注意它通常应当只创建一次；多个客户端共享同一个 Transport 也可以，但必须明确谁负责配置和关闭空闲连接。

按正文用途选择读取方式

如果正文是业务数据，就把它读完并在结束时关闭；如果只需要前几个字节，就限制读取上限；如果完全不需要正文，直接关闭即可，但要接受旧版本或大正文场景下可能失去 HTTP/1 复用。

func readPreview(client *http.Client, url string) ([]byte, error) {
    // 只有拿到响应后才注册 Close，避免对 nil Body 解引用。
    resp, err := client.Get(url)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    // 限制读取量，防止“只看摘要”的路径把整个响应读入内存。
    preview, err := io.ReadAll(io.LimitReader(resp.Body, 4

如果你明确知道正文很小，或者为了兼容较早的 Go 版本而希望主动读到 EOF，可以使用 io.Copy(io.Discard, resp.Body) 后再关闭；不要对未知大小的下载响应无条件这样做，否则会把本来不需要的内容完整读过网络。对大文件下载，常见做法是把正文写入目标文件，而不是为了连接复用额外保留一份内存副本。

Go 版本和协议边界要分开看

Go 官方关于 HTTP 连接复用的说明指出，Go 1.27 的 net/http.Transport 会对部分未读的 HTTP/1 响应体进行有限的异步 drain，预算是最多约 50 毫秒或 256 KB，并会避开明确标记为关闭连接的情况。这个优化降低了“只关心状态码”场景的复用损失，但不改变下面三条工程规则：

• 调用方仍要关闭每个已经拿到的 Response.Body。
• 兼容 Go 1.26 及更早版本时，想主动争取复用就应根据正文大小决定是否读取到 EOF。
• HTTP/2 使用多路复用，未读某个流的正文不会以同样方式阻塞其他流，但正文生命周期仍需正确结束。

如果看到连接数持续上涨，优先检查是否反复创建 Client/Transport、是否遗漏了 Body.Close、是否在只读状态码时留下大量未读正文，以及服务端是否明确发送了 Connection: close。不要只靠调大 MaxIdleConnsPerHost 掩盖这些生命周期问题。

速查表：什么时候读完，什么时候只关闭

最终可以把这条规则放进代码评审清单：Client/Transport 是否复用，非空响应的 Body 是否关闭，正文是否按用途读取，连接池参数是否和实际并发匹配。四项都清楚，Transport 才能在正确的边界内复用连接。

相关问题

• 只调用 resp.Body.Close 就一定能复用连接吗？不一定；旧版本和 HTTP/1 大正文场景可能因为未读完而放弃连接。
• 为什么不能每次请求都创建 Transport？新 Transport 没有上一批请求留下的空闲连接，连接池复用优势会被抵消。
• io.Copy(io.Discard, Body) 应该总是调用吗？不应该；只在正文大小可控或确实需要读完整响应时使用。