Go HTTP 请求耗时怎么拆：httptrace.ClientTrace 与 RoundTripper 计时该怎么选

线上接口报“偶发变慢”时，只看一条 total=xxms 往往不够：慢在 DNS、建连、等首字节，还是服务端已经处理完却卡在读取响应，修复方向完全不同。Go 标准库里，http.RoundTripper 适合量请求总耗时，httptrace.ClientTrace 适合把一次请求拆成可核对的阶段。

要看接口整体是否变慢，用 RoundTripper 做统一计时；要回答“慢在哪一段”，把 httptrace.ClientTrace 挂到请求上下文里。两者不是二选一，生产上通常是外层总耗时加按需开启的阶段追踪。

先把“总耗时”和“阶段耗时”分开

RoundTripper 位于 HTTP 客户端的传输边界。把原始 Transport 包一层，就能在 RoundTrip 返回前后记录时间。它回答的是“这次请求从发出到拿到响应头花了多久”，实现简单，适合放进统一客户端、指标中间件或日志字段。

但总数本身没有解释力。一次 200 毫秒的请求，可能是 150 毫秒等待连接，也可能是服务端 150 毫秒后才返回首字节。第二种情况要看服务处理，第一种情况要看连接复用、DNS 或网络路径。

基线命令以 mode=roundtripper 运行；终端结果中的 status=200 OK 和 total=19ms，就是本节要保留的两个可核对字段。

用 RoundTripper 做一层稳定的总耗时指标

下面的复现实例没有引入第三方包：服务端固定等待 18 毫秒后返回 ok，客户端只记录 http.Get 前后的时间。这样先建立一个基线，再看更细的阶段信息。

start := time.Now()
resp, err := http.Get(server.URL)
if err != nil { panic(err) }
_ = resp.Body.Close()
fmt.Printf("status=%s total=%s\n", resp.Status, time.Since(start).Round(time.Millisecond))

这层计时适合做长期观测：请求方法、目标服务、状态码和总耗时放在同一条结构化日志里，告警规则也更容易保持稳定。它不需要理解 DNS 或连接复用的细节。

需要定位阶段时，再接入 ClientTrace

httptrace.ClientTrace 通过请求上下文接收网络阶段事件。示例关注 DNSStart/DNSDone、ConnectStart/ConnectDone 和 GotFirstResponseByte。最后一个回调只说明首字节已经到达，不代表响应体已经读完。

trace := &httptrace.ClientTrace{
    ConnectStart: func(_, _ string) { connect = time.Now() },
    ConnectDone:  func(_, _ string, _ error) { /* 记录连接阶段 */ },
    GotFirstResponseByte: func() { /* 记录首字节 */ },
}
req = req.WithContext(httptrace.WithClientTrace(ctx, trace))

本地 httptest.Server 使用回环地址，通常不会触发可观测的 DNS 或新建 TCP 连接，所以不要因为终端里没有 dns= 就判断 ClientTrace 失效。连接复用正是 HTTP 客户端的一种正常状态；真正需要查 DNS 或建连时，应换成可控的独立地址并明确记录环境。

本次运行的关键输出是 connect=0s、first_byte=recorded、mode=trace、status=200 OK、first_byte_seen=true 和 total=20ms。这些字段分别对应连接阶段、首字节回调、响应状态和外层总计时。

两种方式怎么选：看你要回答的问题

常见坑：不要把阶段回调拼成错误的总和

阶段之间存在重叠，连接可能复用，HTTP/2 也会改变事件形态；把 DNS、连接、首字节简单相加，往往会得到一个比真实请求更大的数字。正确做法是保留各事件时间点或独立时长，并用外层 total 做最终核对。

另一个坑是只记录错误请求。超时请求当然要保留阶段信息，但成功请求的采样也很重要，否则没有正常基线，无法判断“慢”到底偏离了多少。

相关问题

RoundTripper 能看到 DNS 耗时吗？

单独包 RoundTripper 看不到 DNS 子阶段；它只适合记录传输调用整体耗时。

ClientTrace 会改变请求行为吗？

它主要注册回调并通过上下文接收事件，回调里不要做阻塞工作，也不要修改请求状态。

生产环境应该一直开启所有回调吗？

总耗时可以常驻，阶段回调建议按采样、错误或指定请求开启，并限制日志字段数量。

小结

RoundTripper 负责回答“整体花了多久”，ClientTrace 负责回答“网络阶段发生了什么”。先用总耗时建立统一口径，再用阶段事件缩小排查范围，最后回到服务端、连接池或网络配置验证修复结果。