Go HTTP Client 不复用连接时怎么检查 Response.Body 关闭

Go HTTP Client 出现“每次请求都像新建连接”时，先别急着调大连接池。最常见的检查顺序是：确认 err == nil 后的 resp.Body 一定会关闭；需要复用 HTTP/1.x 连接时，尽量把响应体读到 EOF；再用 httptrace 观察 GotConnInfo.Reused。只看 resp.Body != nil 不够，因为 Body 是否关闭是一个生命周期状态。

先把 Response.Body 的关闭责任固定下来

http.Client.Do 成功返回时，resp.Body 保证非空。推荐在拿到响应后立刻登记关闭责任，避免业务代码在解析、分支返回或错误处理时漏掉它：

resp, err := client.Do(req)
if err != nil {
    return fmt.Errorf("发送请求失败: %w", err)
}
defer resp.Body.Close() // 统一释放响应体，提前 return 也不会遗漏

body, err := io.ReadAll(resp.Body)
if err != nil {
    return fmt.Errorf("读取响应失败: %w", err)
}
if resp.StatusCode/100 != 2 {
    return fmt.Errorf("服务端返回 %s: %s", resp.Status, body)
}
return nil

如果只需要判断状态，不需要保存响应内容，也不要把 Body 留给下游。可以先读到丢弃设备，再关闭；这比只调用 Close 更明确地表达“本次响应已消费完”。但响应很大或来自不可信服务时，应设置上限，不能无条件把无限流量读入内存。

用 bodyTracker 检查到底有没有调用 Close

想排查某个分支是否漏关，可以在测试或临时诊断版本里包一层 io.ReadCloser。它不改变读取内容，只记录读取字节数、是否见到 EOF，以及 Close 是否被调用：

type bodyTracker struct {
    io.Reader
    closer io.Closer
    readN  atomic.Int64
    eof    atomic.Bool
    closed atomic.Bool
}

func (b *bodyTracker) Read(p []byte) (int, error) {
    n, err := b.Reader.Read(p)
    b.readN.Add(int64(n)) // 记录消费量，避免把“未读取”误判成“未关闭”
    if errors.Is(err, io.EOF) {
        b.eof.Store(true) // EOF 只能说明读完，不代表调用方已经 Close
    }
    return n, err
}

func (b *bodyTracker) Close() error {
    b.closed.Store(true) // 记录业务侧是否履行关闭责任
    return b.closer.Close()
}

func checkBody(resp *http.Response) (*bodyTracker, error) {
    tracked := &bodyTracker{Reader: resp.Body, closer: resp.Body}
    resp.Body = tracked
    defer tracked.Close() // 示例函数结束时无论解析是否失败都关闭
    _, err := io.Copy(io.Discard, tracked)
    if err != nil {
        return tracked, err
    }
    return tracked, nil
}

诊断时重点看两组状态：closed=false 是确定的关闭遗漏；eof=false、closed=true 表示提前关闭，Transport 可能尝试有限度地读完，但不能把它当成稳定复用保证。包装器只适合诊断和测试，不要在生产热路径上为每个请求增加额外日志。

用 httptrace 区分新建连接和连接复用

Body 已经关闭但连接仍不复用，下一步要看连接池事实，而不是猜。httptrace.ClientTrace.GotConn 会给出 GotConnInfo，其中 Reused 表示本次取得的连接是否来自空闲连接池；PutIdleConn 则帮助判断连接有没有被放回池中：

var reused atomic.Bool
var idleErr atomic.Value

trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        reused.Store(info.Reused) // false 表示本次没有拿到复用连接
    },
    PutIdleConn: func(err error) {
        idleErr.Store(err) // nil 表示 Transport 接受了空闲连接
    },
}

req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close() // 先保证响应体生命周期完整
_, err = io.Copy(io.Discard, resp.Body)
if err != nil {
    return err
}
log.Printf("reused=%v idle=%v", reused.Load(), idleErr.Load())

真正的判断要放在连续请求中：第一次请求的 Reused=false 很正常；第二次仍为 false，才值得继续查 Body 是否读完、是否关闭、服务端是否发送 Connection: close，以及请求是否走了 HTTP/2。PutIdleConn 对 HTTP/2 当前不提供同样的回调，因此不能把它当成所有协议的统一指标。

客户端生命周期和常见误判

http.Client 与 Transport 应该创建一次并复用。每次函数调用都 new 一个 Client，即使 Body 正确关闭，也没有机会复用前一个 Client 的连接池。相反，调用 CloseIdleConnections 会主动清掉空闲 keep-alive 连接，适合退出或隔离场景，不适合放在每个请求之后。

因此，排查顺序应固定为“关闭责任 → 读取边界 → trace 信号 → Client/Transport 生命周期 → 服务端和协议条件”。这样能把 Body 遗漏与正常的新建连接分开。

常见问题

只调用 resp.Body.Close，不读完响应，可以吗？

可以释放资源，但不保证 HTTP/1.x 连接复用。若响应体很小且希望稳定复用，优先读到 EOF 后关闭；大响应则按业务设置上限。

Response.Body 关闭了，为什么 Reused 还是 false？

可能是第一次请求、服务端主动关闭、请求使用了不同的 Client，或当前连接走的是 HTTP/2。需要连续请求并结合 GotConnInfo、响应头和协议版本判断。

每次请求后都要调用 CloseIdleConnections 吗？

不需要。它会关闭空闲连接，通常应在客户端退出、租户隔离或明确回收连接池时使用。

参考资料

• Go net/http Client.Do：Response.Body 关闭与连接复用说明。
• Go net/http Response：Body 的读取和关闭语义。
• Go httptrace.ClientTrace：GotConn 与 PutIdleConn 诊断钩子。