Go httptrace.GotConn 如何判断 HTTP 请求是否复用了连接

如果 HTTP 客户端偶尔出现连接建立变慢、Keep-Alive 没有按预期生效，先不要只看总耗时。Go 标准库可以在一次请求取得连接后触发 httptrace.ClientTrace.GotConn，从参数 httptrace.GotConnInfo 读取 Reused。这个布尔值为 true，表示当前连接此前已经服务过另一个 HTTP 请求；为 false，则表示它不是这样的一条已使用连接。

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

最小判断方式是：给请求上下文挂上 ClientTrace，在 GotConn 回调里读取 info.Reused；需要解释空闲池来源时，再结合 WasIdle 和 IdleTime。不要读取、写入或关闭回调里的 Conn。

为什么只看 HTTP 响应时间不够

一次请求变慢，可能发生在 DNS、建连、TLS、等待服务端响应或读取响应体等不同位置。总耗时只能告诉我们“慢了”，不能直接说明连接池有没有复用已有连接。

GotConn 适合补上这条连接层信号：它发生在 Transport 成功取得连接之后。把 Reused 写入请求日志，就能把“本次请求拿到的是曾经使用过的连接，还是一条新连接”与请求耗时放在同一条记录里。它是观测字段，不是性能结论；复用成功也不等于服务端一定更快。

GotConnInfo 里真正要读哪个字段

GotConnInfo 里有四个对理解连接状态有帮助的成员。业务代码通常只需要把布尔值和空闲时长复制到自己的日志结构，不要把 Conn 保存为长期状态。

把 ClientTrace 放入请求上下文

接入点是 httptrace.WithClientTrace。它根据原有上下文生成一个带追踪钩子的上下文，再用 req.WithContext 生成请求副本。下面的示例只记录连接状态，不触碰底层连接对象。

package main

import (
    "context"
    "log"
    "net/http"
    "net/http/httptrace"
)

func requestWithConnectionTrace(ctx context.Context, client *http.Client, url string) (*http.Response, error) {
    trace := &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            // Reused 回答是否曾服务过其它 HTTP 请求；WasIdle 补充是否来自空闲池。
            log.Printf("http connection reused=%t was_idle=%t idle_time=%s",
                info.Reused, info.WasIdle, info.IdleTime)
            // Conn 归 http.Transport 所有，这里不读取、不写入，也不调用 Close。
        },
    }

    tracedContext := httptrace.WithClientTrace(ctx, trace)
    req, err := http.NewRequestWithContext(tracedContext, http.MethodGet, url, nil)
    if err != nil {
        // URL 构造失败时直接返回，避免把无效请求交给 Client。
        return nil, err
    }

    resp, err := client.Do(req)
    if err != nil {
        // GotConn 只在成功取得连接后触发；请求失败仍以 Do 的错误为准。
        return nil, err
    }
    return resp, nil
}

这里的检查点有两个：一是 GotConn 只负责记录状态，二是 client.Do 返回响应后，调用方仍要按正常 HTTP 资源边界关闭 resp.Body。回调日志如果会被多个请求同时写入，应使用线程安全的日志或指标组件。

Reused、WasIdle、IdleTime 怎么一起解释

单看 Reused=true 已经可以回答标题问题，但另外两个字段能帮助定位连接池现象：

• Reused=true：当前连接以前已经服务过其它 HTTP 请求。
• WasIdle=true：当前连接来自空闲池；这能说明它在取得前不是刚刚新建的活动连接。
• IdleTime：在 WasIdle=true 时，表示此前空闲了多久；不要在 WasIdle=false 时把它解释成一次有效的空闲时长。

因此，“复用”与“从空闲池取出”是相关但不同的观察角度：前者回答连接过去是否服务过请求，后者回答取得来源是否是空闲池。把三个字段作为同一个日志对象保存，比只打印一句“复用了连接”更容易解释异常。

把复用信号写进一次请求日志

真实项目里，回调和请求主流程通常需要共享一个很小的观测结构。结构只保存值，不保存 net.Conn，这样既能关联请求日志，也不会越过 Transport 的所有权边界。

type connectionObservation struct {
    reused  bool
    wasIdle bool
    idle    time.Duration
}

func newTrace(observation *connectionObservation) *httptrace.ClientTrace {
    return &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            // 只复制可解释的观测值，避免把 Transport 管理的 Conn 带出回调。
            observation.reused = info.Reused
            observation.wasIdle = info.WasIdle
            observation.idle = info.IdleTime
        },
    }
}

这段片段展示的是字段关系，完整函数还需要导入 net/http/httptrace 和 time，并在每个请求中创建独立的观测对象。不要让多个并发请求共用一个可变对象，否则日志字段可能互相覆盖。

采用时要守住四个边界

1. 它观察的是连接取得，不是失败原因。如果 Transport 没有成功取得连接，GotConn 不会替代 Do 返回的错误；失败处理仍看请求错误。
2. 它不覆盖完整重定向链。ClientTrace 的追踪范围是单次 round trip，不能把一次回调当成整个重定向序列的总览。
3. 它不授予底层连接所有权。Conn 属于 http.Transport，不要在回调中读写或关闭。
4. 它不是复用率指标本身。如果要统计比例，应明确分母、请求范围和并发窗口，并保证回调写入组件具备并发安全性。

一条稳妥的落地路径

可以按下面的顺序接入，而不改变现有请求语义：

1. 先给单个客户端请求挂上 ClientTrace，只记录 Reused。
2. 确认日志能够把观测值和请求目标、请求 ID 关联起来，再追加 WasIdle 与 IdleTime。
3. 把回调改写为轻量指标或采样日志，避免在回调内执行阻塞 I/O。
4. 最后再把复用信号和请求耗时、错误类型放在同一观察面板里，区分“未复用导致建连成本增加”和“已复用但服务端仍慢”这两类问题。

常见问题

Reused 为 true 就一定来自空闲连接池吗？

不能只靠这个字段下结论。Reused 表示此前服务过其它 HTTP 请求；是否从空闲池取得，应单独看 WasIdle。

可以在 GotConn 回调里读取 Conn 的地址吗？

不建议这样做。官方文档明确说明该连接由 http.Transport 所有，调用方不应读写或关闭。需要观测连接状态时，优先使用 Reused、WasIdle 和 IdleTime。

为什么请求失败时没有 GotConn 日志？

该回调是在成功取得连接后调用的；连接取得失败时，应该结合 client.Do 或 Transport 返回的错误判断。

只看 Reused 能不能证明连接池配置正确？

不能。它只能提供一次请求的连接复用事实，连接池上限、空闲时间、Keep-Alive、协议版本和服务端行为仍需分别观察。

总结

Go 中判断 HTTP 请求是否复用了连接，关键不是猜测响应耗时，而是在请求上下文里安装 httptrace.ClientTrace，于 GotConn 回调读取 GotConnInfo.Reused。需要进一步解释连接来源时，加入 WasIdle 和 IdleTime；始终把 Conn 留给 Transport 管理。这样得到的是清晰、低侵入的连接层事实，后续才能和耗时、错误及连接池指标放在一起分析。