http.RoundTripper是唯一靠谱入口，因它能捕获DNS解析、TLS握手、连接复用等待、响应体流式读取等全链路耗时，而Client.Do或业务层打点会遗漏关键环节；必须通过嵌套Transport劫持RoundTrip和Response.Body.Close来实现毫秒级精准统计。
为什么 http.RoundTripper 是唯一靠谱的入口
go 的 http 客户端耗时统计不能靠包装 http.client.do 或在业务层打点——那些只覆盖到请求发起后、响应读取前，漏掉 dns 解析、tls 握手、连接复用等待、响应体流式读取等关键环节。真正能捕获全链路（从 roundtrip 调用开始，到响应 body 关闭为止）的，只有自定义 http.roundtripper。
它天然位于标准库调用栈最底层，所有 http.Client 请求最终都会流经这里，且能拿到原始 *http.Request 和 *http.Response，也方便注入上下文追踪 ID。
- 别试图用中间件或装饰器包装
Do方法：无法感知连接池阻塞、Read阻塞等底层耗时 - 不要在
Response.Body.Read里埋点：流式响应可能分多次读，总耗时不等于各次之和 -
http.Transport本身是RoundTripper的默认实现，直接嵌套它是最安全的扩展方式
如何用嵌套 Transport 实现毫秒级全链路计时
核心思路是：在 RoundTrip 开始前记录起始时间，在返回的 *http.Response 的 Body.Close 被调用时记录结束时间。注意——必须劫持 Response.Body，否则无法捕获读取完成的真实终点。
type TimingRoundTripper struct {
base http.RoundTripper
}
func (t *TimingRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
start := time.Now()
resp, err := t.base.RoundTrip(req)
if err != nil {
recordMetric(req.URL.Host, "error", time.Since(start).Milliseconds())
return resp, err
}
// 包装 Body，确保 Close 时打点
resp.Body = &timingReadCloser{
ReadCloser: resp.Body,
req: req,
start: start,
}
return resp, nil
}
type timingReadCloser struct {
io.ReadCloser
req *http.Request
start time.Time
}
func (t *timingReadCloser) Close() error {
defer t.ReadCloser.Close()
dur := time.Since(t.start).Milliseconds()
recordMetric(t.req.URL.Host, "total", dur)
return nil
}
- 必须用
time.Since而非time.Now().Sub：避免时钟回拨导致负值 - 错误路径也要打点：
RoundTrip失败时，连接未建立或 TLS 失败等耗时同样重要 - 别在
RoundTrip返回后立刻打点：此时响应头已收到，但 Body 可能还没读完，不算“请求完成”
哪些耗时维度值得单独拆解
光有总耗时不够。DNS、TLS、连接建立、首字节（TTFB）、响应体传输这些细分阶段，对定位网络或服务瓶颈至关重要。Go 标准库不暴露这些钩子，但可通过 http.Transport.DialContext 和 TLSClientConfig.GetClientCertificate 等间接埋点。
- DNS 耗时：用自定义
net.Resolver包装LookupHost，记录解析前后时间 - TLS 握手：在
http.Transport.TLSClientConfig的GetClientCertificate或VerifyPeerCertificate中插桩（注意并发安全） - 连接建立：替换
Transport.DialContext，在net.DialContext前后计时 - TTFB：在
RoundTrip返回后，立即读取响应头（resp.Header可用即代表首字节到达），再启动 Body 读取计时
注意：TLS 和 DNS 钩子可能被复用连接跳过，需结合连接 ID 或 req.URL 做去重判断，否则同一连接多次请求会重复上报。
生产环境必须绕开的三个坑
本地跑通不等于线上可用。以下问题在线上高并发场景下极易暴露：
- 内存泄漏：如果忘记在
timingReadCloser.Close中调用原ReadCloser.Close，连接不会归还连接池，http.Transport.MaxIdleConnsPerHost会被快速耗尽 - 指标爆炸：对每个请求都打点并直传监控系统（如 Prometheus Pushgateway），QPS 上千时会压垮指标后端；应聚合采样，比如每 100 个请求打 1 个点
- 上下文丢失：若请求带
context.Context，需确保所有计时回调不阻塞主 goroutine，且不意外延长 context 生命周期（例如在 goroutine 中异步上报时忘了用context.WithTimeout）
最隐蔽的问题是：某些代理或负载均衡器会复用 TCP 连接但修改响应头，导致你误以为 TTFB 很短——实际是复用连接省掉了建连时间，但业务逻辑仍卡在后端。全链路统计必须和后端日志的 trace_id 对齐，否则单看客户端耗时毫无意义。
