最准最轻量的耗时统计是中间件中用time.Now()和defer，但无法解决DB查询、JSON序列化等真实瓶颈；需替换c.JSON()、按需加载中间件、复用缓冲区才能显著降延迟。
直接在中间件里用 time.Now() 和 defer 记录耗时，是最准、最轻量的方式；但想靠它把接口从 100ms 优化到 10ms，基本没用——瓶颈从来不在计时逻辑本身，而在你没关掉的中间件、没复用的对象、和每次都在重新反射的 c.JSON()。
为什么耗时统计中间件不能替代性能分析
很多人写完耗时中间件就以为“能看见慢在哪了”，结果发现 /api/users 平均 85ms，但根本看不出是 DB 查询、JSON 序列化，还是某个中间件里的 log.Printf 拖垮的。因为：
-
c.Next()只告诉你“整个链路花了多久”，不拆解内部耗时 - 日志中间件如果同步写磁盘，单次就占 300–800μs，但它在耗时统计里只算作“业务处理时间”的一部分
- panic 后的
Recovery()会遍历 goroutine 栈，开销不可控，但耗时统计可能已提前结束 - 如果你把耗时写进响应头（如
X-Response-Time），它测的是“写出响应的时间”，不是“业务逻辑完成时间”——gzip 中间件放它后面，测的就是压缩+传输耗时
真正影响毫秒级响应的三个实操点
别再只盯着中间件加减法。下面三点改完，P95 延迟常能降 30% 以上：
-
替换
c.JSON()：用jsoniter.ConfigFastest预编译 +c.Data()直写。标准c.JSON()因反射和堆分配，1KB payload 实测约 120μs；换掉后压到 45μs 左右 -
按需加载中间件：把
router.Use(auth, logger)拆成局部注册。比如/health路由完全绕过 auth；/metrics接口只挂限流中间件，不挂日志 -
复用缓冲区：高频 JSON 解析/拼接场景下，用
sync.Pool缓存*bytes.Buffer。未复用时一个请求平均分配 7 次小对象；复用后分配次数归零，P99 延迟下降约 12%
耗时统计中间件怎么写才不出错
写对了是监控基础，写错了反而掩盖问题。关键就三条：
- 起始时间必须在
c.Next()前记：start := time.Now()，且不能放在defer里 - 结束计算必须用
defer包裹：defer func() { c.Set("latency", time.Since(start)) }()，否则 handler 提前c.Abort()会导致时间漏算 - 别在中间件里做同步 I/O：
log.Printf改异步通道；写文件、调远程服务一律移出主链路；c.Writer.Header().Set()必须在c.Next()后、响应未写出前调用，否则 panic 报header already written
最易被忽略的是：耗时统计本身不该成为性能瓶颈。比如你在 /metrics 接口里对 sync.Map 做全量排序算 P95，高并发下这个接口自己就会拖慢整个服务——该在每次写入时就维护好滚动 min/max/sum/count，而不是等查的时候再算。
