Gin中路由级拦截必须用router.Group()绑定中间件，禁用路径字符串匹配；耗时统计需在c.Next()前后用time.Now()精确测量，采样用哈希方案，响应头写入须在c.Next()后且未写出前。
怎么在 Gin 中实现路由级请求拦截
必须用 router.Group() 绑定中间件，而不是靠路径字符串匹配或手动判断 c.Request.URL.Path。Gin 的路由树不支持运行时重匹配，硬编码路径判断不仅难维护，还会漏掉带参数的路径（比如 /user/:id）和通配符路径（/*filepath）。
常见错误是写一个“万能中间件”，在里面用 strings.HasPrefix(c.Request.URL.Path, "/admin") 做判断——这会绕过 Gin 的路由匹配逻辑，导致权限校验失效、c.Param() 拿不到值、甚至和 recovery() 执行顺序错乱。
- 正确做法：用
r.Group("/admin")创建分组，再调用.Use(AuthMiddleware()) - 权限中间件里必须显式调用
c.Abort()中断流程，否则即使鉴权失败，后续 handler 仍会执行 - 如果要对部分子路径放行（如
/admin/login不鉴权），得在分组内单独注册不带中间件的路由，不能靠 if 判断跳过
为什么自定义耗时统计总比 gin.Logger() 更准
gin.Logger() 的耗时起点是中间件函数入口，包含日志格式化、I/O 写入等开销；而真实服务耗时应从路由匹配完成、handler 开始执行前算起。生产环境必须自己写中间件，在 c.Next() 前记时间，在 c.Next() 后取差值。
直接用 gin.LoggerWithConfig() 改 Formatter 只能清理 query，解决不了计时偏差问题，且默认仍会打印敏感 body（哪怕你没读它，c.Request.Body 也会被 gin.Logger() 消费一次）。
立即学习“go语言免费学习笔记（深入）”；
- 务必在
c.Next()前调用start := time.Now() - 务必用
defer包裹耗时计算，否则c.Next()panic 时逻辑不执行 - 状态码必须用
c.Writer.Status()，不是c.Status()—— 后者只返回 header 设置值，未触发 WriteHeader 时是 0
耗时数据怎么打出来才不拖慢服务
高 QPS 下同步写日志（log.Printf 或 fmt.Println）会锁 stdout，成为性能瓶颈。结构化日志库（如 zerolog 或 zap）配合异步 writer 是底线，但更关键的是采样控制。
别用 math/rand.Float64() 做采样——它不是并发安全的，多 goroutine 调用可能 panic 或采样率失控。哈希方案更稳：对 c.Request.URL.Path + c.Request.RemoteAddr 做 fnv 哈希，再 % 100 判断是否记录完整日志。
- 采样率建议设为
sampleRate float64 = 0.01（1%），全局变量即可，无需 mutex - 响应头写入（如
X-Response-Time）必须在c.Next()之后、且c.Writer.Header().Set()前确保响应未写出，否则 panic - 如果用了
gzip中间件，耗时中间件必须放在它前面，否则测的是压缩耗时，不是 handler 真实耗时
怎么让耗时排行按路由聚合输出
Gin 本身不提供内置的耗时排行功能，得靠外部指标系统（如 Prometheus）或自己缓存最近 N 条请求的路径+耗时，再定时排序。但要注意：内存缓存必须无锁，别用 map + mutex，改用 sync.Map 或分片 map。
最简可行方案是用 promhttp 暴露 http_request_duration_seconds 指标，配合 histogram_vec 按 path 和 method 标签维度聚合——比自己维护排行榜更可靠、更易对接 Grafana。
如果非要本地排行，别每条请求都排序，而是用 heap 维护 Top-K，插入 O(log K)，避免全量排序开销。另外注意：同一路径下不同参数（/user/123 vs /user/456）应归为同一 key，否则排行失去意义，得提前用正则或 Gin 的 c.FullPath() 归一化路径。
