应自定义 http.roundtripper 包装 defaulttransport，在 roundtrip 入口用 time.now() 打点，全程记录 dns、连接、ttfb、响应读取等阶段耗时，并在 resp 或 err 返回时补全 end 时间；需 wrap body 测读取耗时，兼容 nil resp，用 context 透传 traceid 而非全局 map。
用 http.RoundTripper 拦截请求并记录耗时
Go 标准库的 http.Client 本身不暴露请求生命周期钩子，但允许你自定义 Transport，而 http.RoundTripper 是其核心接口。直接替换默认 Transport 是最轻量、侵入性最小的方式——所有通过该 Client 发出的请求都会经过你的统计逻辑。
常见错误是试图在 http.HandlerFunc 或中间件里统计（那仅适用于服务端接收请求），而第三方调用是客户端行为，必须从发出侧入手。
实操建议：
- 实现一个包装型
RoundTripper，内部持有原http.RoundTripper（通常是&http.Transport{}） - 在
RoundTrip(*http.Request)方法中，用time.Now()打点，调用原RoundTrip，再计算差值 - 避免在耗时统计中做阻塞操作（如写文件、同步发 HTTP 上报），应异步投递到 channel 或使用带缓冲的队列
- 注意：
RoundTrip可能被并发调用，统计逻辑需线程安全；但耗时本身是 per-request 的，不需要锁，只需确保上报聚合逻辑（如计数器）是原子或加锁的
用 prometheus.HistogramVec 做分维度耗时分布
单纯记录平均耗时意义有限，真实监控需要看 P90/P95、失败率、按接口路径或状态码切分。Prometheus 的 HistogramVec 是最常用选择，它支持多标签（labels），比如你可以按 endpoint="https://api.example.com/v1/users"、method="POST"、status_code="200" 维度打点。
容易踩的坑：
- 标签值不能动态生成大量唯一值（如带用户 ID 的 URL），否则会导致指标爆炸（cardinality disaster）。应提前对 URL 做路径模板化，例如把
/users/123归一为/users/{id} -
HistogramVec的Buckets要覆盖业务实际延迟范围，比如后端 API 多数在 100ms 内，但偶尔有 2s 查询，建议设为[]float64{0.01, 0.05, 0.1, 0.25, 0.5, 1, 2, 5}（单位秒） - 别在每次
RoundTrip中调用histogram.WithLabelValues(...).Observe(...)—— 这会重复解析 label 字符串；应预先缓存prometheus.Labels或用With()获取子向量
处理重试、超时、连接错误等非 2xx 场景
第三方接口不稳定，RoundTrip 可能返回 err != nil（如网络超时、DNS 失败、TLS 握手失败），也可能返回 resp.StatusCode >= 400。这两类错误统计方式不同：前者代表请求根本没发出去或中途断了，后者代表服务端已响应但语义失败。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
实操建议：
- 对
err != nil，仍应记录耗时（从开始到出错的时间），并打上result="error"标签，同时额外记录error_type="timeout"或"dns"等（可从err.Error()或类型断言提取） - 对
resp.StatusCode >= 400，记录正常耗时，并打result="failure"和status_code=strconv.Itoa(resp.StatusCode) - 若使用了重试（如
github.com/hashicorp/go-retryablehttp），务必只统计最终那次请求的耗时，而不是每次重试——否则 P95 会被严重拉高。可在重试 wrapper 外层统一封装 RoundTripper
避免 context.WithTimeout 干扰真实耗时测量
很多 Go 项目会在发起请求前用 ctx, cancel := context.WithTimeout(ctx, 5*time.Second)，但这会导致 RoundTrip 在超时后返回 context deadline exceeded 错误，此时测得的“耗时”是接近 5s 的值，而非真实网络耗时。这会让 P99 统计失真，掩盖真正慢的请求。
正确做法是：在 RoundTrip 内部用独立的计时器，完全绕过 context 的超时影响。即：
start := time.Now() resp, err := rt.RoundTrip(req) duration := time.Since(start) // 这才是真实网络+服务端处理时间
而 context 超时只用于控制是否继续等待，不影响统计口径。如果你需要区分“服务端处理慢”和“客户端主动放弃”，可以额外记录 was_cancelled_by_context 标签。
复杂点在于：有些错误（如 net/http: request canceled）可能由外部 cancel 触发，也可能是底层连接池关闭导致，需结合 errors.Is(err, context.Canceled) 判断，而不是只看错误字符串。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
