Go HTTP/1 客户端怎样检查连接复用是否生效

检查 Go HTTP/1 客户端是否复用连接，最直接的方法是在请求 Context 上挂载 httptrace.ClientTrace，观察 GotConn 中的 Reused。再结合 WasIdle、响应协议和 PutIdleConn 判断连接是否来自空闲池。不要只看耗时，也不要把“调用了 Body.Close”直接等同于下一次请求必定复用。

先把问题缩小到同一目标的串行请求

一个常见场景是：循环请求同一服务，两次都很快，却不知道 TCP 连接是否重复建立。耗时会受缓存、网络和业务处理影响，无法单独回答连接复用问题。先用同一 Transport、同一目标、两次串行请求建立最小观察场景，再回到实际服务扩展。

本文讲的是 HTTP/1 连接池，不把 HTTP/2 多路复用混入判断。示例使用 Go 1.24 及以上提供的 Protocols 配置，仅启用 HTTP/1，并输出实际 resp.Proto。

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

追踪接口：https://pkg.go.dev/net/http/httptrace

先改掉容易误判的写法

连接池由 Transport 管理。每次创建新的 Transport，会让请求分散到不同池里；反过来，创建不同 Client 却仍共享同一个 Transport，也不能据此认定完全没有复用。排查时应追踪实际使用的 Transport，而不是只数 Client 对象。

另一个误区是在很长的请求循环中不断 defer resp.Body.Close，却要等外层函数结束才关闭这些响应体。将单次请求封装成小函数，或者在本轮读取结束后立即关闭，更容易控制资源生命周期。

这些是观测方式与资源用法的调整，不是某个新版本才改变的复用规则。不要为了解决问题先把连接池容量调得很大，而忽略请求实际使用了哪个池。

用 GotConn 观察两次串行请求

下面完整示例保存为 main.go 后可运行。服务端返回固定的小响应，客户端关闭代理并限定 HTTP/1，减少公网与代理环境的干扰。这段代码用于读者在本地观察，不代表本文已经运行过并取得固定输出。

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "net/http/httptest"
    "net/http/httptrace"
    "time"
)

// probe 每次独立完成响应体读取与关闭，避免在大循环末尾才释放。
func probe(client *http.Client, target string, id int) error {
    req, err := http.NewRequest(http.MethodGet, target, nil)
    if err != nil {
        return err
    }
    trace := &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            // 只观测连接信息，不直接操作 Transport 拥有的连接。
            log.Printf("请求%d reused=%t idle=%t idleTime=%s",
                id, info.Reused, info.WasIdle, info.IdleTime)
        },
        PutIdleConn: func(err error) {
            log.Printf("请求%d idlePoolErr=%v", id, err)
        },
    }
    req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    // 本例响应很小且已知有限，完整消费可避免下一次请求赶上排空过程。
    _, readErr := io.Copy(io.Discard, resp.Body)
    closeErr := resp.Body.Close()
    log.Printf("请求%d protocol=%s status=%s", id, resp.Proto, resp.Status)
    if readErr != nil {
        return fmt.Errorf("读取响应体: %w", readErr)
    }
    if closeErr != nil {
        return fmt.Errorf("关闭响应体: %w", closeErr)
    }
    return nil
}

func main() {
    // 本地有限响应，隔离公网代理、负载均衡和服务端主动断连的影响。
    server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Length", "4")
        _, _ = io.WriteString(w, "pong")
    }))
    defer server.Close()

    tr := http.DefaultTransport.(*http.Transport).Clone()
    // Go 1.24及以上：本例只启用HTTP/1，避免混入HTTP/2多路复用。
    tr.Protocols = new(http.Protocols)
    tr.Protocols.SetHTTP1(true)
    tr.Proxy = nil
    tr.DisableKeepAlives = false
    tr.MaxIdleConns = 8
    tr.MaxIdleConnsPerHost = 2
    tr.IdleConnTimeout = 30 * time.Second
    defer tr.CloseIdleConnections()

    client := &http.Client{
        Transport: tr,
        Timeout: 5 * time.Second,
    }
    // 两次请求共用同一个Transport，并且串行执行。
    for id := 1; id 

# 在支持http.Protocols的Go工具链下运行本地示例。
go run main.go

在本例条件下，预期首次取到新连接，后一次可观察到 Reused 为 true。若没有出现，应先看错误、协议与服务端连接行为，不把预期当成保证。GotConn 暴露的连接由 Transport 拥有，不要为了“核验”而在回调里直接读取、写入或关闭它。

响应体完整消费与及时关闭各有作用

HTTP/1 中应关注的是响应体 resp.Body，而不只是请求体。对于本例这种已知有限的小响应，io.Copy 到 io.Discard 可以消费到 EOF，再显式 Close。两项错误分别处理，避免读取失败后仍按“完整响应”理解。

当前官方文档还说明，Transport 在关闭响应体时会尝试在保守限额内异步排空。因此“未手动读完就一定无法复用”也太绝对。但自动排空有边界，且可能尚未完成，不适合当成任何响应都能即时复用的承诺。

生产中不要为了复用，无条件丢弃读取未知大小或持续输出的响应。应设定业务读取策略和超时；遇到过大或不可信响应时，可以选择结束读取并接受该连接不再复用。若业务只解析了一个 JSON 值，也不能据此推断底层 HTTP 响应已经读到结束。

结合连接池与协议定位原因

本地示例正常、实际服务仍频繁新建连接时，按下面的证据顺序收窄范围。先记录实际协议、目标、错误和复用标记，避免在尚未确认 HTTP/1 的情况下套用空闲池判断。

MaxIdleConnsPerHost 控制每个目标保留的空闲连接数量，不是该目标全部连接数的统一上限。需要限制每个目标的总连接数量时，应理解 MaxConnsPerHost 的作用；它也可能带来等待，不能只为了让“新建数下降”而盲目压低。

不要在每轮请求后调用 CloseIdleConnections 再期待空闲连接继续留在池里。它更适合明确的清理时机。本例只在程序退出时清理。

添加计数时，也要明确分母。一次逻辑请求可能涉及重定向或内部重试，GotConn 回调数量不总等于业务请求数量；回调可能并发执行，生产计数应采用同步安全的实现。日志只保留必要信息，不记录认证头或敏感URL参数。对同一负载比较调整前后的观测，才能说明修改影响了什么。

常见问题

新建 Client 就一定失去复用吗？

不一定，关键看实际 Transport 是否共享。为了更清晰地管理超时、重定向和连接池，通常会复用配置好的 Client 和 Transport。

把 MaxIdleConnsPerHost 调大一定有效吗？

不一定。响应没有正常结束、服务端主动关闭、池对象不共享等问题，都不会仅靠增大空闲容量解决。

Reused 为 true 就代表请求成功了吗？

不代表。它描述取到的连接历史，请求仍可能在后续读写中失败，应同时检查 Do 和响应体读取错误。

为什么只出现一次 PutIdleConn 也不能直接判定异常？

回调不是逐请求成功证明。协议、复用开关、响应结束和连接状态都会影响其触发，需结合 GotConn、实际协议与错误解释。