Go net/http 怎样让 HTTP1 响应体关闭后复用连接

HTTP/1 响应体使用完后必须关闭。Go 1.27 的默认 Transport 会在 Body.Close 后异步尝试排空尚未读取的内容，但有保守限制；它改善复用机会，不承诺“关闭即复用”。对大小可控、需要完整内容的响应，读完再关闭仍是清晰的资源管理方式。

官方地址：https://go.dev/

以下是一个短读接口的教学排查情境，不是真实事故记录，也没有本机运行数据。协议范围限定 HTTP/1；HTTP/2 不应套用同一连接串行占用模型。

连接数量增长时，先确认影响的是哪一层

设想一个轮询程序只关心状态码，却发现新建连接增多。不能马上认定连接泄漏：并发需求、服务端主动关闭、空闲超时和不共享 Transport 都可能造成新连接。先记录请求协议、状态码、读取错误及后续请求是否复用，避免仅凭请求成功就判断连接已回池。

沿着短读与关闭时机梳理线索

按代码发生顺序检查三个位置：Do 返回后是否只读了前缀，出错分支是否遗漏 Close，循环内的 defer 是否直到整个函数返回才释放。这里的顺序是阅读代码的方法，不是已经观察到的线上时间线。

若每轮都创建独立 Transport，连接池便被拆散；若所有请求共用 Transport，仅新建 Client 也不等于创建全新连接池。不要用 Client 对象数量代替池的归属判断。

关闭响应体，不代表消息边界已完整读取

HTTP/1 的后续响应需要清晰的消息边界。Go 1.27 将有限自动排空加到关闭路径，调用方仍须 Close；异步排空意味着 Close 返回不等于连接已经可供下一次请求使用。超大正文、慢响应、读取错误或连接关闭条件下，都不应依赖复用保证。依据见 Go 1.27 net/http 变更 与 Response.Body 契约。

不要把自动排空上限写成业务常量，也不要为了复用无条件读取任意长度正文。LimitReader 达到上限产生的 EOF 属于包装层，不能证明原始 Body 已读到真正结尾。

用有界读取和小函数收拢关闭责任

下例读取不超过 1 MiB 的业务响应，并额外读一个字节判断超限。较小响应完整读完，超限响应及时关闭，接受可能不复用的结果。Client.Timeout 限制请求整体时间；它与正文大小限制解决不同问题。示例把读取和关闭错误都返回，不把 4xx、5xx 当成 Do 的网络错误。

package fetch

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

// 在循环外创建，所有请求共用同一个 Transport 和连接池。
var pool = http.DefaultTransport.(*http.Transport).Clone()
var client = &http.Client{Transport: pool, Timeout: 8 * time.Second}

func FetchSmall(ctx context.Context, url string) (data []byte, err error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }
    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    // 每次函数返回即关闭，不把 defer 堆到外层轮询函数。
    defer func() { err = errors.Join(err, resp.Body.Close()) }()

    const maxBody = 1  maxBody {
        // 主动放弃大正文；不为了连接复用继续无限排空。
        return nil, fmt.Errorf("响应体超过 %d 字节", maxBody)
    }
    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("HTTP 状态码 %d", resp.StatusCode)
    }
    return data, nil
}

这个函数适用于小响应，不适用于大文件、长连接事件流或必须保留错误正文的 SDK。若要保留错误正文，应定义单独且有界的返回字段，而不是把可能含敏感信息的完整正文写入日志。代码未在本任务执行。

采用默认 Transport 的克隆，是为了继承默认配置后按业务修改；不要并发修改正在使用的 Transport。本文没有强制只协商 HTTP/1，实际协议仍需看 resp.Proto；只有 HTTP/1 请求才应用这里的排空解释。

用后续请求的连接事件判断复用

下面片段放在 FetchSmall 的 client.Do(req) 之前，先引入 log 和 net/http/httptrace。它记录当前请求取得的连接；要判断前一个响应释放后的效果，应比较后续请求的事件，而不是把第一次请求的 Reused 当成前一个 Close 的结果。

// 记录连接来源，不读写或关闭追踪信息中的 Conn。
trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        log.Printf("reused=%t idle=%t idle_time=%s",
            info.Reused, info.WasIdle, info.IdleTime)
    },
}
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

读者可在可控服务上串行发出小响应请求，记录协议和连接事件，再改变响应大小、关闭策略、超时配置作比较。不要在生产流量上为追求复用强行排空无界响应，也不要把本节当成已执行的测试报告。

防复发可归结为：响应体责任归一、循环内及时释放、共享池、有限正文、明确超时。不要随意将 MaxIdleConns 设为 0 来“限制连接”，在 Transport 中它表示不限制总空闲连接数量；DisableKeepAlives 则会关闭复用，只有明确不需要复用的场景才考虑。这里的配置影响可参阅 Transport 文档。

只读取状态码也要 Close 吗？

要。Go 1.27 改善的是关闭后处理未读内容的行为，不会把调用方的关闭责任取消。

用了 LimitReader 就能确认读完吗？

不能。限制层也会制造 EOF。示例多读一个字节识别超限，超过预算便退出，不承诺复用。

没有复用就一定有 bug 吗？

不是。远端关闭、超时、并发和池策略都可能影响结果。先区分协议和错误，再讨论是否需要优化。

相关官方参考：io 的限量读取语义、GotConnInfo 字段定义。本文示例与图示均为原创教学材料。