Go问答：httptrace 如何定位 HTTP 连接未复用：ClientTrace 回调与 Transport 生命周期

我排查 Go HTTP 客户端连接数时，最容易误判的一点是：请求成功，不等于连接被复用。真正有用的判断不是盯着响应耗时，而是把 httptrace.ClientTrace 绑定到请求上下文，观察 GotConnInfo.Reused 和 WasIdle，再回头检查 Response.Body 与同一个 Transport 的生命周期。

官方地址：https://pkg.go.dev/net/http/httptrace

先分清 GetConn、GotConn 与 PutIdleConn 的观测含义

这三个回调对应的是不同边界。GetConn 表示 Transport 开始为目标主机获取连接，即使空闲池里已经有连接也会触发；GotConn 表示连接已经拿到，适合读取 GotConnInfo；PutIdleConn 则表示连接尝试回到空闲池，参数为 nil 才代表回收成功。HTTP/2 当前不使用 PutIdleConn 这条回调，所以它为空不能直接推出连接泄漏。

GotConnInfo 里最关键的是三个字段：Reused 表示该连接以前是否服务过请求，WasIdle 表示它是否从空闲池取出，IdleTime 只在 WasIdle=true 时有解释价值。排查时不要只记录“连上了”，而要把这三个字段和目标 host 一起记录。

把 ClientTrace 绑定到请求并记录 GotConnInfo

下面的最小示例只负责观察，不读取、关闭或改写底层 net.Conn。这点很重要：连接由 http.Transport 所有，GotConn 中只读取公开状态即可。

trace := &httptrace.ClientTrace{
    GetConn: func(hostPort string) {
        // 记录目标主机，说明 Transport 开始寻找或建立连接。
        log.Printf("get-conn host=%s", hostPort)
    },
    GotConn: func(info httptrace.GotConnInfo) {
        // Reused、WasIdle、IdleTime 用来区分新连接和空闲池连接。
        log.Printf("got-conn reused=%t idle=%t idle_time=%s",
            info.Reused, info.WasIdle, info.IdleTime)
    },
    PutIdleConn: func(err error) {
        // nil 表示连接成功回到空闲池；非 nil 只说明本次回收失败。
        log.Printf("put-idle err=%v", err)
    },
}

req, err := http.NewRequestWithContext(
    httptrace.WithClientTrace(context.Background(), trace),
    http.MethodGet,
    "https://example.com/health",
    nil,
)
if err != nil {
    // 请求创建失败时先返回，避免把无效请求误算成连接问题。
    return err
}
resp, err := client.Do(req)
if err != nil {
    // RoundTrip 失败不会触发 GotConn；这里保留真实网络错误。
    return err
}
defer resp.Body.Close()
_, err = io.Copy(io.Discard, resp.Body) // 读完响应体，给 HTTP/1.1 复用留下条件。
return err

实际项目里，client 应该长期复用，而不是每次请求都新建一个带新 Transport 的客户端。这样日志才有机会观察到同一连接池的连续状态。

检查 Transport 复用条件与响应体生命周期

如果第二次请求的 Reused=false，我会按下面的顺序排查，而不是先把连接池上限调得很大：

官方 Response.Body 说明给出了关键边界：想让底层 Transport 复用持久连接，通常要把 body 读到 EOF 并关闭。只写 defer resp.Body.Close() 但提前返回，可能仍然让 HTTP/1.x 连接无法复用。反过来，调试阶段也不要把 CloseIdleConnections 当成修复手段，它只是关闭当前空闲连接。

用结果矩阵解释 HTTP/1.1 与 HTTP/2 边界

把日志组合起来看更可靠：GotConn 触发且 Reused=false，说明本次取得的不是以前成功使用过的连接；Reused=true 且 WasIdle=true，通常就是从空闲池取回；Reused=true 但 WasIdle=false，不要马上认为异常，HTTP/2 多路复用或并发争用都可能让连接仍在使用中。

如果你看到 GotConn 正常、请求也成功，但 PutIdleConn 没有日志，先确认是不是 HTTP/2。若是 HTTP/1.1，再看响应体是否完整消费、服务端是否发送了关闭信号、代理是否截断 keep-alive。最后才考虑调整 MaxIdleConnsPerHost 或 IdleConnTimeout。

相关问题

为什么 GetConn 有日志但 GotConn 没有？

GetConn 是开始获取连接的通知，连接建立或取得失败都可能发生在它之后；失败时使用 client.Do 返回的错误定位，不要把 GetConn 当成成功信号。

只关闭 Response.Body 不读取内容够不够？

不能把它当成稳定的复用保证。优先读完 body 再关闭，尤其是 HTTP/1.x；Go 可能在关闭时异步读取有限剩余内容，但业务代码不应依赖这个保守行为。

调整 MaxIdleConnsPerHost 后仍然不复用怎么办？

先确认所有请求是否共享同一个 Transport，再看 DisableKeepAlives、响应体关闭、服务端关闭和 HTTP 版本。空闲连接上限只影响池中保留多少条连接，不能修复错误的生命周期。