Go HTTP 客户端连接复用失效怎样检查响应体读取

Go HTTP 客户端的连接复用失效，第一检查点不是状态码，而是 resp.Body 的生命周期：请求成功后是否读到了响应体末尾，是否在所有返回路径关闭了它，以及是否复用了同一个长期存活的 http.Client 或 http.Transport。这三个条件没有被同时满足时，后续请求可能反复建立 TCP 连接，表现为延迟上升、连接数变多或抓包里一直看不到复用。

把“读取响应体”和“关闭响应体”看成一个不可拆开的职责单元，再用 httptrace.GotConn 的 Reused 观察结果。只看 StatusCode，无法证明连接是否被复用。

响应体生命周期才是连接复用的关键

http.Client.Do 在没有错误时会返回非空的 Response.Body，调用方负责在使用完成后关闭它。Go 官方文档还特别说明：如果响应体既没有读到 EOF，也没有关闭，底层的 Transport 可能无法把持久连接交给下一次 keep-alive 请求。也就是说，HTTP 语义中的“收到 200”与连接池语义中的“这条 TCP 连接还能复用”是两件事。

把这个关系画成静态结构，更容易发现责任边界：Client 负责高层请求策略，Transport 持有连接缓存，Response 暴露 Body，读取器消费字节，关闭动作向 Transport 表明当前响应已经结束。下面的图是结构说明，不是运行截图。

典型实现：把读取与关闭放进同一个函数

最稳妥的做法是让一个小函数同时承担状态检查、正文读取和关闭责任。调用方拿到的是已经完成读取的字节，避免在业务分支里先判断状态、后提前返回，最后忘记释放 Body。

package main

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

// readResponseBody 统一消费并关闭响应体，避免业务分支遗忘 Close。
func readResponseBody(resp *http.Response) ([]byte, error) {
    // 调用方只在 resp 非空且 err 为 nil 时进入这里。
    defer resp.Body.Close()

    // ReadAll 会持续读取到 EOF，适合正文大小受控的接口。
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, fmt.Errorf("读取响应体失败: %w", err)
    }
    if resp.StatusCode = 300 {
        // 非 2xx 也要先完成关闭，再把状态信息交给上层处理。
        return nil, fmt.Errorf("HTTP 状态异常: %s", resp.Status)
    }
    return body, nil
}

func fetch(client *http.Client, url string) ([]byte, error) {
    // Client 应由上层长期复用，不要为每次请求临时创建 Transport。
    resp, err := client.Get(url)
    if err != nil {
        return nil, err
    }
    return readResponseBody(resp)
}

这个模板的重点不是必须使用 io.ReadAll，而是把释放点放在响应体所有路径都能经过的位置。正文很大时，可以改成流式解码或写入文件，但仍要在同一职责边界内关闭 Body；不要因为改成 json.Decoder 或 io.Copy 就删掉关闭逻辑。

用 GotConn 的 Reused 字段观察连接是否复用

要检查“复用失效”是否真的发生，可以在请求上下文里挂上 httptrace.ClientTrace。每次 Transport 获得连接时，GotConn 都能收到连接信息，其中 Reused 表示这条连接之前是否已经服务过请求。第一次通常是新连接，不能拿第一次结果作为失败证据；重点应放在相同客户端连续请求的后续样本。

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "net/http/httptrace"
)

func requestWithReuseTrace(client *http.Client, url string) error {
    reused := false
    trace := &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            // Reused 只说明连接曾被使用，不等于响应内容正确。
            reused = info.Reused
            fmt.Printf("连接复用=%v 空闲=%v\n", info.Reused, info.WasIdle)
        },
    }

    req, err := http.NewRequestWithContext(
        httptrace.WithClientTrace(context.Background(), trace),
        http.MethodGet,
        url,
        nil,
    )
    if err != nil {
        return fmt.Errorf("创建请求失败: %w", err)
    }

    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("发送请求失败: %w", err)
    }
    // 无论状态码如何，都要在当前请求结束前关闭响应体。
    defer resp.Body.Close()
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return fmt.Errorf("消费响应体失败: %w", err)
    }
    fmt.Printf("本次请求是否拿到复用连接: %v\n", reused)
    return nil
}

这里特意保留了“先消费，再关闭”的完整边界：GotConn 只负责观察连接，不能替代响应体处理。连续调用同一个 client 时，如果服务端和协议条件允许，后续请求的 Reused 才有比较价值。

只需要状态码时，为什么也不能随手返回

有些接口只关心 204、304 或某个错误状态码，业务代码可能写成“看完状态码就 return”。这正是响应体被遗忘的高发位置。即便正文通常为空，也应保持一致的资源处理习惯；如果响应体可能携带未消费内容，则应先消费到合适的边界，再关闭。

func checkStatus(client *http.Client, url string) error {
    resp, err := client.Get(url)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    // 只关心状态码时仍先读完当前响应，避免把未消费内容留给 Transport。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return fmt.Errorf("读取状态响应失败: %w", err)
    }
    if resp.StatusCode != http.StatusNoContent {
        return fmt.Errorf("期望 204，实际是 %s", resp.Status)
    }
    return nil
}

对于很大的错误响应，不应为了复用而无限制地把错误正文读进内存。可以使用受限读取，把诊断需要的少量内容保存下来，再关闭响应体；连接能否复用还会受到服务端是否主动关闭、请求是否取消以及协议版本的影响。

反例：新建 Client、提前返回与错误归因

以下几种写法经常被误认为是“Transport 不复用”，但它们的共同问题是生命周期和观测混在了业务分支里：

• 每次函数调用都创建新的 http.Client 或 http.Transport，连接缓存没有机会跨请求存活。
• 拿到响应后只读取前几个字节，随后因为状态码不符合预期直接返回。
• 只在成功分支关闭 Body，错误状态、解析失败或超时分支没有统一清理。
• 把第一次请求的 Reused=false 当成故障，忽略了连接复用至少需要可比较的后续请求。

Transport 本身是带内部连接状态的对象，官方文档建议复用它，并说明它可以安全地被多个 goroutine 并发使用。客户端复用并不意味着每个请求都必须复用连接：HTTP/2、多主机访问、服务端关闭连接、超时取消和网络错误，都可能让某一次请求自然拿到新连接。

排查时应记录哪些证据

可以按下面的顺序收窄问题，但它们是判断维度，不是要求在代码里硬编码的执行流程：

最后可以把检查收敛成一句话：先确认同一个 Client/Transport 仍然存在，再确认每个响应体都被消费到合适边界并关闭，最后用连续请求的 Reused 记录判断结果。不要用一次状态码、一次抓包或第一次连接结果替代这三个层次。

常见问题

只调用 resp.Body.Close，不读取正文可以吗？

必须关闭；是否能复用还取决于响应体是否已经读完以及 Transport 的处理边界。对需要稳定复用的普通 HTTP/1.x 响应，显式消费到 EOF 再关闭更容易让意图清楚。

读到 EOF 后还需要 Close 吗？

需要。读取到 EOF 解决的是响应内容边界，Close 解决的是资源生命周期；二者不是同一个动作。

Reused 一直是 false，是不是代码一定有问题？

不一定。先确认是否复用了同一个 Client、目标主机是否相同、请求是否被取消、服务端是否主动关闭连接，以及是否比较了第二次及之后的请求。

错误响应也要读完吗？

仍要关闭。若错误正文较小，可以消费后记录；若正文可能很大，可限制读取量，保存必要诊断信息后关闭，不要无上限读入内存。

资料来源

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

Go 官方 Transport 源码说明：https://go.dev/src/net/http/transport.go

Go 官方连接复用文章：https://go.dev/blog/http-connection-reuse