timing记录必须紧挨next.ServeHTTP()前注册defer，因defer在函数返回前执行，仅此位置能确保下游handler（含Write/WriteHeader/流式Body读取）真正完成；若放开头则panic恢复或提前return会导致耗时不完整，且前置中间件逻辑（如JWT、gzip）也会被误计入。
Go HTTP 中间件里 timing 记录必须放在 next.ServeHTTP() 前
不是“越早越好”，而是必须紧挨着 next.ServeHTTP() 调用之前注册 defer。因为 Go 的 defer 是函数返回前才执行，只有放在这里，才能确保下游 handler（包括所有 Write、WriteHeader、流式响应的 Body 读取）真正执行完毕。
常见错误是把 start := time.Now() 和 defer 都写在函数开头，结果 handler panic 后被 recover，或提前 return，time.Since(start) 拿到的是不完整耗时；更隐蔽的问题是：如果前面还有 JWT 验证、gzip 等中间件，那段逻辑也会被计入——但你可能只想看业务 handler 自身耗时，那就得把 timing 中间件往链路后挪。
-
start必须在defer之前赋值，且不能被后续逻辑覆盖 - 别用
time.Now().Sub(start)，直接用time.Since(start)，语义清晰、精度一致 - 如果 handler 内部启动 goroutine 异步写响应（比如 SSE），
time.Since会低估真实延迟——这时必须靠包装ResponseWriter+ 拦截Write才能捕获真正发送完成时间
为什么一定要包装 ResponseWriter 才能拿到真实状态码和字节数
标准 http.ResponseWriter 不暴露已写入的状态码。w.WriteHeader(404) 调用后，你从原始 w 上调用 w.Header().Get("Content-Length") 或查状态都拿不到。不包装就只能默认记 200，日志完全失真。
自定义结构体只需嵌入原 w，重写 WriteHeader 方法并保存 statusCode 即可。注意：WriteHeader 里不要做耗时操作，否则阻塞响应；也别漏掉对 Write 的拦截——大响应体写入本身也耗时。
立即学习“go语言免费学习笔记（深入）”；
- 必须用字段标记是否已调
WriteHeader，避免重复写头导致http: multiple response.WriteHeader calls -
Write方法里累加bytesWritten，但要注意：如果 handler 没显式调WriteHeader，Write第一次调用会隐式写200 OK - 别在 wrapper 里主动调
wrapped.WriteHeader()，除非确定 status 未设
Gin 中间件里怎么安全写入响应头记录耗时
Gin 的 c.Writer 是个接口，直接调 c.Writer.Header().Set() 即可把耗时写进响应头，适合前端调试；但必须在 c.Next() 之后、且响应未写出前设置，否则会 panic 报 header already written。
写日志更适合后端监控，但注意：log.Println 同步输出在高并发下会成为瓶颈；建议用 zap 或 zerolog 这类结构化日志库异步写入。另外，耗时统一转 Milliseconds() 后四舍五入（%.0fms），避免日志里出现 12.000000ms 这种干扰项。
- 路径必须用
r.URL.Path，别试图从gorilla/mux的r.Context().Value()还原路由模板（没匹配上就 panic） - 别在日志里拼
r.URL.String()——query 参数可能含敏感信息或长 token - 如果用了 gzip 中间件，压缩耗时会算进 handler 总耗时，这是对的；但若 handler 自己开 goroutine 写响应，
time.Since就会低估真实延迟
为什么响应时间统计常比真实慢 1–5ms
这不是代码问题，而是 Go runtime 在 2026 年仍存在的调度特性：time.Now() 获取的时间戳受系统时钟抖动与 goroutine 切换延迟影响，尤其在高负载下，next.ServeHTTP() 返回后到 defer 执行之间存在微小空隙。这个偏差稳定在 1–5ms，无法靠调整代码消除。
真正反映用户感知延迟的，是 ResponseWriter 实际写入字节并 Flush 的时刻。所以生产环境必须把计时终点锚定在写响应完成之后，而不是 handler 函数返回时——这要求你在包装器的 Write 或 Flush 方法里触发最终打点，而非依赖 defer。
多数人忽略的是：即使你写了完美中间件，只要没包装 ResponseWriter 并监听 Write，就永远拿不到真实完成时间。这个细节在压测和 SLA 分析中会直接暴露出来。
