context不用于传递耗时数据，只负责取消信号、截止时间和少量元数据；耗时统计应在context生命周期内打点并上报，绑定done()通道触发最终计算，避免用withvalue存time.time或耗时差值。
Go 中用 Context 传耗时统计不成立，得换思路
Context 不是用来传递耗时数据的。它只负责传递取消信号、截止时间、少量元数据（如 trace_id），本身不存指标、不记录时间点、也不支持写入耗时差值。硬往 context.WithValue 里塞 elapsed 或 start_time，不仅违反 Context 设计原则（仅用于请求范围元数据，非计算结果），还会让调用链变重、难以观测、无法聚合。
真正该做的：用 Context 控制耗时采集生命周期
耗时统计不是“传出来”，而是“在 Context 生命周期内打点并上报”。关键在于把计时逻辑绑定到 Context 的 Done() 通道上，确保无论因超时、取消还是正常结束，都能触发最终耗时计算。
- 服务端中间件中，用
time.Now()在入口打起点，监听ctx.Done()或响应完成时算终点 - 客户端用
httptrace.ClientTrace，所有钩子函数都接收ctx，可安全读取ctx.Value("trace_id")关联指标 - 数据库查询必须用
QueryContext/ExecContext等带 Context 的方法，否则耗时统计和取消会脱节 - 避免在
ctx.Value存time.Time类型变量——它不可比较、不序列化、GC 友好性差；改用int64纳秒戳或直接打点后立刻计算
HTTP 客户端怎么拿到 DNS/连接/TLS 各阶段耗时
标准 http.Client 不暴露底层网络事件，必须靠 httptrace。它不修改 Context，但所有 trace 回调都运行在原始请求 ctx 下，可安全取值、打日志、发指标。
trace := &httptrace.ClientTrace{
DNSStart: func(info httptrace.DNSStartInfo) {
log.Printf("DNS start for %s", info.Host)
},
DNSDone: func(info httptrace.DNSDoneInfo) {
log.Printf("DNS done in %v", info.Err)
},
ConnectStart: func(network, addr string) {
// 这里可以记录连接开始时间
},
GotFirstResponseByte: func() {
// 首字节到达，常作为“后端处理耗时”终点
},
}
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
-
httptrace的回调函数本身不返回耗时，你需要自己维护开始时间（例如在ConnectStart存到ctx.Value，但 key 必须是自定义类型，不能用string） - 更稳妥的做法是：在每个回调里直接记录当前纳秒时间戳 + 事件名，后续统一归并分析
- 别依赖
ctx.Deadline()推算剩余时间来决定是否继续 trace——它可能为 zero time，且与网络阶段无直接关系
为什么服务端中间件里不能只靠 time.Since(start)
看似简单的一句 duration := time.Since(start)，在真实场景下容易漏掉三类耗时：
- WriteHeader 之后、实际写响应体之前的时间（比如模板渲染慢、流式响应卡住）
- defer 写日志时，
rw.statusCode可能未被正确捕获（比如 panic 导致 handler 提前退出） - 中间件外层还有 net/http 本身的 TLS 握手、keep-alive 复用等开销，不在 handler 范围内
真正健壮的做法是包装 ResponseWriter，重写 Write 和 WriteHeader，并在 Write 第一次调用时打“响应开始”点，在 Write 返回后或 panic 恢复时打“响应结束”点——这些动作都必须发生在同一个 ctx 下，才能保证 trace ID 不丢、超时判断不偏移。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
