Go 问答：httptrace.ClientTrace GotConnInfo 怎么判断连接是否复用：连接池与请求时序边界

排查 Go HTTP 客户端连接池时，不能只看请求耗时猜连接有没有复用。给请求挂上 httptrace.ClientTrace，在 GotConn 回调里读取 GotConnInfo.Reused，就能知道这条连接以前是否服务过其他请求；如果还要判断它是不是刚从空闲池取出，再看 WasIdle 和 IdleTime。

Reused=true 表示连接曾被使用过，WasIdle=true 表示本次取得它时来自空闲池；两者不是同一个判断。只有把 Response.Body.Close、PutIdleConn 和下一次 GotConn 放在同一条时序里，才能解释复用结果。

先把“复用”拆成两个问题

线上看到连接数上涨时，最容易把“连接复用”和“从空闲池取连接”当成一回事。官方的 GotConnInfo 同时提供了 Reused、WasIdle 和 IdleTime，但它们回答的是不同问题。

• Reused：这条连接以前是否已经用于另一个 HTTP 请求。
• WasIdle：这次获取是否命中了空闲连接池。
• IdleTime：只有 WasIdle 为真时，才表示此前空闲了多久。

所以，Reused=true、WasIdle=false 并不矛盾：连接可能刚从另一个请求结束后直接交给当前请求，尚未进入空闲池。

用 ClientTrace 记录真实连接时序

下面的示例只记录连接获取结果，不读取或关闭 GotConnInfo.Conn。这几个节点正好对应 GetConn、GotConnInfo 和 RoundTrip 的调用链。

trace := &httptrace.ClientTrace{
    GetConn: func(hostPort string) {
        log.Printf("GetConn host=%s", hostPort)
    },
    GotConn: func(info httptrace.GotConnInfo) {
        log.Printf("GotConn Reused=%t WasIdle=%t IdleTime=%s",
            info.Reused, info.WasIdle, info.IdleTime)
    },
}

req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
resp, err := http.DefaultClient.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close()

第一条日志只能证明 GetConn 已开始；第二条日志出现在成功取得连接之后。连接获取失败不会通过 GotConn 报告，最终错误要从 Transport.RoundTrip 或客户端请求返回值判断。

为什么关闭响应体会影响下一次判断

连接是否能回到空闲池，还要看响应体消费和关闭是否完成。ClientTrace.PutIdleConn 会在连接返回空闲池时触发；官方文档还特别说明，它发生在调用方的 Response.Body.Close 返回之前。这个回调在 HTTP/2 下当前并不使用，不能把缺少它当成 HTTP/2 连接没有复用。

排查 HTTP/1.x 连接时，可以把日志按下面的顺序对齐：

1. 请求 A 进入 GetConn，随后在 GotConn 看到连接属性。
2. 请求 A 读取响应，并执行 Response.Body.Close。
3. 如果连接成功回池，PutIdleConn(nil) 表示回池动作没有错误。
4. 请求 B 再次进入 GetConn，在 GotConnInfo 中观察 Reused 与 WasIdle。

这里别急着把 WasIdle=false 判定成“连接池失效”。请求 B 可能拿到的是刚完成请求 A 的连接；还要同时检查请求 A 是否完整读取响应、是否关闭了响应体，以及传输协议是否为 HTTP/2。

三个常见误判怎么排除

只记录 Reused，不记录 WasIdle

这样能回答连接是否曾经使用过，却回答不了它是否来自空闲池。连接池老化、空闲时间和刚刚交接的连接会被混在一起。建议至少同时打印 Reused、WasIdle 与 IdleTime。

在 GotConn 回调里操作 Conn

GotConnInfo.Conn 由 http.Transport 所有，业务代码不应读取、写入或关闭它。需要记录身份时只记录布尔字段与时长，别把连接生命周期交给回调。

把 PutIdleConn 当成所有协议的回池信号

官方说明 HTTP/2 当前不使用 PutIdleConn。如果请求走的是 HTTP/2，应结合协议协商结果、请求错误和服务端指标判断，而不是等待这个回调出现。

一组可复查的验收日志

实际验收时，建议给每个请求带上 request id，并按顺序保存 GetConn、GotConnInfo、PutIdleConn 和 Response.Body.Close 事件。看到请求 B 的 Reused=true 只能证明连接曾经被使用；看到 WasIdle=true 才能进一步证明它从空闲池取出。

如果两个请求之间始终没有复用，继续检查 Transport.DisableKeepAlives、服务端是否主动关闭连接、响应体是否提前放弃读取，以及是否已经切换到 HTTP/2。每一项都要由日志或协议观察结果支持，不要只按耗时推断。

相关问题

GotConnInfo.Conn 可以用来判断是不是同一条 TCP 连接吗？

它是传输层管理的连接对象，不建议业务代码直接操作。诊断时优先使用 Reused、WasIdle 和时序日志。

IdleTime 为零是不是没有复用？

不是。只有 WasIdle=true 时，IdleTime 才有空闲池语义；应先判断 WasIdle。

请求失败时一定会触发 GotConn 吗？

不会。GotConn 表示成功取得连接；连接获取失败要查看请求返回的错误。

总结

判断 Go HTTP 连接复用，先用 GotConnInfo.Reused 回答“以前是否用过”，再用 WasIdle 和 IdleTime 判断是否从空闲池取出。把 Response.Body.Close、PutIdleConn 和下一次 GotConn 对齐后，连接池问题才有完整证据链。