gin中间件是流量统计起点，因其能统一拦截所有请求，避免手动埋点遗漏；但需分组隔离高频/监控路径、控制执行顺序、用atomic.int64+sync.rwmutex保障线程安全，并正确暴露prometheus指标。
为什么 Gin 的中间件是流量统计的起点
直接在路由 handler 里埋点容易漏、难复用，而 Gin 的 gin.HandlerFunc 中间件能统一拦截所有请求，天然适合做流量采集。但别一上来就写全局中间件——高频接口（如健康检查 /healthz）和静态资源路径会严重污染统计数据。
- 先用
engine.Use()注册全局中间件，再通过engine.Group().Use()对业务路由分组隔离 - 跳过
/metrics、/debug/pprof等监控自身路径，避免自循环打点 - 注意中间件执行顺序：Gin 按注册顺序串行执行，统计中间件必须在鉴权、日志等之后（否则可能因 panic 或重定向中断）
如何用原子计数器安全记录 QPS 和总请求数
用 sync.Map 存路径维度计数？错——高并发下 LoadOrStore 仍可能丢失更新。真正轻量且线程安全的做法是每个路由路径配一个 atomic.Int64，配合 sync.RWMutex 管理路由元信息（比如是否启用统计、超时阈值）。
- 初始化时预热常见路径（如
GET /api/v1/users），避免运行时动态创建锁竞争 - 每秒刷新一次 QPS：用
time.Tick启动 goroutine，把上一秒的计数器值原子交换为 0，并存入环形缓冲区（长度 60） - 别用
time.Now().Second()对齐整秒——系统时钟跳跃会导致重复或漏算
暴露 Prometheus metrics 时绕过 Gin 的路由冲突
Gin 默认不支持 http.Handler 直接挂载，而 Prometheus 的 promhttp.Handler() 是标准 handler。硬塞进 gin.WrapH() 会丢掉 path prefix 语义，导致 /metrics 返回 404。
- 正确做法：用
gin.RouterGroup.Any("/metrics", gin.WrapH(promhttp.Handler())) - 如果用了反向代理（如 Nginx），确保 upstream 配置透传
X-Real-IP，否则所有请求来源 IP 都是 127.0.0.1 - 暴露的指标名必须带应用前缀，例如
dashboard_http_request_total，避免与业务服务指标混用
前端轮询 metrics 接口时被浏览器缓存坑了怎么办
Chrome 对 GET /api/metrics 默认缓存 5 秒，你看到的 QPS 曲线其实是平滑过的假数据。这不是前端 bug，是 HTTP 协议默认行为。
- 后端加响应头：
c.Header("Cache-Control", "no-store")，比no-cache更彻底 - 前端 fetch 时显式禁用缓存：
cache: 'no-store'，不要依赖Math.random()拼 query 参数 - 别用
setInterval固定间隔轮询——网络延迟叠加后实际间隔会漂移，改用setTimeout链式调用保证每次请求完成后再启下一轮
路径维度统计的精度取决于中间件注册时机和原子操作的覆盖范围，这两个地方出问题，整个看板的数据就不可信。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
