必须在每个中间件内用otel.Tracer.Start()创建独立span，包裹c.Next()前后逻辑并设middleware.name属性，通过span.duration分布（尤其P95）识别长尾瓶颈，避免context.WithValue高频分配和同步I/O阻塞，按注册顺序合理布局中间件以精准分离耗时。
中间件执行链路的性能开销必须实测，不能靠经验猜——因为每个 c.Next() 调用都会引入协程调度与函数跳转成本，而认证、日志、限流等中间件在高并发下容易成为隐性瓶颈。
用 otel.Tracer.Start() 在每个中间件里打点
OpenTelemetry 是目前最轻量、最可控的方式。关键不是“加了追踪”，而是让每个中间件都成为一个独立 span，才能看清谁拖慢了整条链。
- 不要只在 handler 入口打一个 root span；要在每个中间件函数内部调用
tracer.Start(ctx, "middleware.auth")，并确保传入上游 context - 用
defer span.End()包裹整个中间件逻辑，包括c.Next()前后代码（否则会漏掉前置/后置耗时） - 避免在中间件里调用
context.WithValue频繁创建新 context——它比context.WithCancel分配更多内存，P99 延迟会上浮 2–5ms
看 span.duration 分布，别只盯平均值
平均延迟 12ms 没意义，真正要揪的是那 5% 的长尾。比如 middleware.logging 平均 3ms，但 P95 达到 86ms，大概率是日志写磁盘或 JSON 序列化阻塞了 goroutine。
- 检查是否在中间件里做了同步 I/O：如直接写文件、调用未带
context的http.Get、或用time.Sleep做限流 - 对比同一中间件在不同路由下的耗时：如果只在
/api/v1/user上飙升，说明和业务数据规模有关（比如 JWT 解析后查 DB） - 启用 OpenTelemetry 的
trace.SpanKindServer标记，并设置span.SetAttributes(attribute.String("middleware.name", "auth"))，方便在 Jaeger 中按中间件名聚合筛选
c.Next() 执行前后的时间差就是真实中间件开销
Gin 的中间件本质是函数包装器，c.Next() 是控制权交还给后续链的关键跳点。它的前后时间差，才是真正属于该中间件的“净开销”。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
start := time.Now(); c.Next(); log.Printf("total: %v", time.Since(start))—— 这测的是“自己 + 后续所有 handler”的总时间 - 正确写法：
start := time.Now(); c.Next(); midCost := time.Since(start)，但必须放在c.Next()后立即计算，且不能被recover()或 panic 拦截干扰 - 若中间件含异步逻辑（如发 MQ、写 Kafka），需用
span.AddEvent("async.sent")单独记录，不能依赖c.Next()前后时间
警惕中间件注册顺序引发的隐藏放大效应
中间件栈是 LIFO（后进先出），但执行耗时不是线性叠加——越靠前注册的中间件，其 c.Next() 调用包裹的子链越长，统计出来的“自身耗时”会被严重稀释。
- 比如
Recovery注册最早，它测出的耗时 = 自身逻辑 + 所有其他中间件 + handler 全部时间，根本无法反映真实开销 - 把高频、低延迟中间件（如
Logging）放前面，把重逻辑中间件（如Auth、RateLimit）放后面，能更干净地分离测量目标 - 用
gin.DebugPrintRouteFunc查看最终注册顺序，确认实际执行流和你预期一致
真正难的不是埋点，而是区分“中间件本身慢”和“中间件暴露了下游慢”。比如 Auth 耗时突增，可能是 Redis 连接池打满导致 redis.Client.Get 阻塞，而不是中间件代码有问题——这时候得顺着 traceID 去查下游服务的 spans 和 error tag。
