当前位置：首页 > 文章列表 > Golang > Go教程 > Go net/http 怎样利用小响应体自动排空复用连接

Go net/http 怎样利用小响应体自动排空复用连接

来源：17golang原创 2026-11-13 21:36:30 0浏览收藏

如果 Go 程序只关心 HTTP 状态码，却直接关闭一个还没有读完的响应体，HTTP/1 请求可能失去连接复用，后续顺序请求就会反复承担建连成本。Go 1.27 的 net/http.Transport 已经会在 HTTP/1 场景下异步尝试排空未读的小响应体：最多排空 256 KiB，最多等待 50 ms；应用代码通常只需要在不再使用响应体时调用 Close。

官方地址：https://go.dev/blog/http-connection-reuse

这篇文章只讨论响应体关闭、连接复用和顺序请求，不把“排空”误解成所有协议、所有大小的响应都应该完整读完。

先理解：响应头返回了，响应体可能还在连接上

http.Client.Do 返回 *http.Response 时，状态行和响应头已经解析出来，但 resp.Body 仍代表连接字节流中尚未消费的部分。HTTP/1 的多个响应按顺序排列在同一条连接上，Transport 只有确认当前响应已经到达结尾，才知道下一个响应从哪里开始。

因此下面两件事不是一回事：

应用已经拿到 StatusCode，不再需要业务字段。
当前响应体已经被读到末尾，连接具备复用条件。

HTTP响应头、未读响应体和连接复用之间的静态关系图 — 图1：HTTP/1 顺序响应中，响应头已返回但未读响应体仍占据字节流的结构说明图，不是运行截图。

最小改法：不需要内容时也要关闭 Body

只看状态码的请求可以保持下面的形状。关键不是手工把每个字节都复制到 io.Discard，而是在确定不再读取后及时关闭 Body，让当前版本的 Transport 按协议和大小决定是否后台排空。

package main

import (
    "fmt"
    "net/http"
)

func getStatus(client *http.Client, url string) (int, error) {
    resp, err := client.Get(url)
    if err != nil {
        return 0, err
    }
    // 不再读取响应体；及时 Close，让 Transport 处理连接复用机会。
    defer resp.Body.Close()

    // 这里只返回状态码，避免把无用的响应内容读入业务内存。
    return resp.StatusCode, nil
}

func main() {
    status, err := getStatus(http.DefaultClient, "https://example.com/health")
    if err != nil {
        fmt.Println("请求失败:", err)
        return
    }
    fmt.Println("HTTP状态:", status)
}

这个写法同时覆盖了资源释放和连接复用两个责任：业务层不再使用响应体后执行 Close，Transport 再根据 HTTP 版本、响应大小和连接头决定后续动作。不要因为只需要状态码，就省略 Close。

自动排空的边界：小响应、时间和协议

Go 1.27 的行为可以按三个维度理解：

场景	Transport 的处理重点	应用侧建议
HTTP/1，未读体较小	异步尝试排空，最多 256 KiB、最多 50 ms	不需要内容时 Close 即可
HTTP/1，响应很大或很慢	超过排空边界后不值得继续等待	不要强行完整读取来“保证复用”
响应声明 Connection: close	复用已被明确禁止，排空没有收益	按关闭连接处理
HTTP/2	响应以独立流复用连接，未读体不会按 HTTP/1 字节流阻塞下一次请求	仍然 Close，避免资源和流长期占用

Go net/http Transport按协议、大小和时间决定自动排空的静态边界图 — 图2：Transport 将协议、响应大小、时间预算和 Connection 头组合成连接复用决策的结构说明图，不是运行截图。

这里的 256 KiB 和 50 ms 是当前 Go 官方说明的自动排空边界，不应写成应用层必须复制的固定参数。未来实现可能继续演进，业务代码应依赖“正确关闭响应体”这个稳定责任，而不是依赖内部排空细节。

什么时候需要自己读：业务内容和旧版本兼容

如果文章正文、JSON 字段或文件内容本来就是业务结果，就应该正常读取并处理错误；自动排空不是替代业务读取。

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
)

type healthResponse struct {
    Status string `json:"status"`
}

func readHealth(client *http.Client, url string) (healthResponse, error) {
    var result healthResponse
    resp, err := client.Get(url)
    if err != nil {
        return result, err
    }
    // 无论状态码如何，都要关闭响应体；读取错误不能跳过清理。
    defer resp.Body.Close()

    if resp.StatusCode = http.StatusMultipleChoices {
        // 错误响应可能很大，只读取有限字节用于诊断，避免无限吞入内存。
        detail, _ := io.ReadAll(io.LimitReader(resp.Body, 4

在 Go 1.27 之前，若只关心状态码又希望尽量复用 HTTP/1 连接，工程里常见的是在关闭前做有界读取；但这属于兼容旧运行时的折中策略。排空过大的响应或等待慢速服务，可能比重新建连更贵，不能把 io.Copy(io.Discard, body) 当成无条件最佳实践。

把连接复用写进请求流程的门禁

我会把下面几项放进 HTTP 客户端的代码评审清单，而不是只看某个请求函数有没有返回错误：

触发器：每次 Do 或 Get 成功后，都明确谁负责关闭 Response.Body。
权限边界：只有真正需要正文的函数才读取正文；状态探针不要为了“看起来完整”把内容传给业务层。
阶段门禁：状态码判断、正文解码和资源关闭分开处理，任何提前返回路径都不能绕过 Close。
失败处理：错误响应只保留有限诊断信息，慢速或大响应不无限等待排空。
通知复盘：当顺序请求突然出现大量新建连接、延迟升高时，先检查 Body 是否关闭、HTTP 版本和服务端连接头。

这套门禁的核心判断是：应用负责完成生命周期，Transport 负责在有收益时争取复用。把两层职责混在一起，才容易出现“为了复用而无界读取”或“为了省事而不关闭”的极端写法。

常见问题

只调用 resp.Body.Close，不读取内容，连接一定会复用吗？

不一定。Go 1.27 会对 HTTP/1 未读的小响应体异步尝试排空，但大响应、慢响应、服务端声明关闭连接等情况仍可能放弃复用；连接池、服务器策略和网络状态也会影响结果。

HTTP/2 还需要手动把响应体读完吗？

不应为了 HTTP/1 的字节流规则而无条件读完。HTTP/2 使用独立流复用连接，未读响应体不会以同样方式阻塞下一次请求；但不再使用时仍要关闭 Body。

JSON 解码成功后为什么还可能影响复用？

解码器可能在遇到 JSON 结束符后就返回，而响应尾部仍有换行或其他可消费字节。Go 1.27 的 Transport 会在 HTTP/1 场景尝试处理这类小尾部；旧版本则需要根据响应大小和运行时版本考虑有界读取。

应该把 256 KiB 和 50 ms 写进自己的 helper 吗？

通常不应该。它们是 Transport 当前实现的自动排空边界，不是应用 API 承诺。业务 helper 更应该固定“读取所需内容、及时关闭、限制错误响应大小”这些可维护规则。

小结

Go net/http 的正确起点很简单：不再使用响应体时调用 resp.Body.Close()。在 Go 1.27 的 HTTP/1 客户端中，Transport 会对未读小响应体自动做有限的异步排空，尽量保留连接复用；HTTP/2 不需要套用 HTTP/1 的完整排空逻辑。真正需要正文时正常读取，错误正文只做有界诊断，别把内部阈值当成永久配置。

事实参考：https://go.dev/blog/http-connection-reuse、https://pkg.go.dev/net/http。