Gin的QPS指标显示为0或恒定不变的根本原因是未在请求链路中正确打点：promhttp.Handler()仅暴露指标端点，不自动拦截请求；必须手写中间件，在c.Next()前后显式调用CounterVec.Inc()并传入字符串状态码与规范化路径标签，且CounterVec需包级声明、init注册一次；QPS应使用CounterVec而非Histogram或Gauge，PromQL需用rate()配合合理窗口（如30s）计算，并确保抓取间隔≤15s。
为什么Gin的QPS指标总是显示为0或恒定不变
根本原因不是Prometheus没抓到数据，而是你没在请求链路里真正打点。promhttp.Handler()只暴露指标端点，它不自动拦截业务请求——HTTP中间件没写，http_request_total就永远是0。
常见错误包括：只注册了指标变量但没在handler里调用Inc()；用了已废弃的InstrumentHandler（Go SDK 1.26+已标记deprecated）；或者把打点逻辑写在panic之后的defer里，导致漏统计。
- 必须手写中间件，在
c.Next()前后记录开始/结束时间，并显式调用.WithLabelValues(...).Inc() - 状态码要用字符串，比如
"200"，传整数200会panic - 路径标签建议用
c.FullPath()而非c.Request.URL.Path，避免因动态ID生成高基数标签（如/user/123→/user/{id}）
Gin中定义QPS指标该用CounterVec还是Histogram
QPS本质是单位时间请求数，属于累计行为，必须用CounterVec；Histogram适合耗时分布，比如P95响应时间，混用会导致PromQL查不出峰值。
典型误用：用Gauge记“当前QPS”，结果指标跳变剧烈且不可聚合——Gauge反映瞬时值，而QPS是速率，Prometheus靠rate()函数从Counter推导，不是靠采样。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
-
CounterVec标签至少包含[]string{"method", "path", "status"}，顺序必须和WithLabelValues()传参严格一致 - 别在路由处理函数里新建
CounterVec，否则每次请求都注册，触发duplicate metrics collector registrationpanic - 包级变量声明：
var httpReqCounter = prometheus.NewCounterVec(...)，init()里只注册一次
如何从Prometheus里准确查出接口QPS峰值
直接看http_requests_total原始值没意义，它只是累加器。真实QPS要靠rate()函数计算滑动窗口速率，窗口大小选太小（如rate(...[1s])）噪声大，太大（如[5m]）会平滑掉尖峰。
生产环境推荐rate(http_requests_total{job="my-gin-app"}[30s])，再套max_over_time()抓峰值：max_over_time(rate(http_requests_total[30s])[1h:])——这表示过去1小时内每30秒窗口的QPS最大值。
- 确保Prometheus抓取间隔（
scrape_interval）≤15s，否则[30s]窗口可能漏数据 - 标签过滤要精确，比如加
path=~"/api/v1/.*"，避免把健康检查接口也计入 - 如果用
promauto包，变量名别带特殊字符，promauto.NewCounterVec会自动注册，省去MustRegister调用
为什么Gin中间件打点后QPS还是对不上压测工具结果
多数情况是goroutine泄漏或打点位置不对：中间件里c.Next()后才打状态码，但若handler panic未recover，defer不执行，这部分请求就漏计；或者并发量高时，WithLabelValues()内部map查找成为瓶颈，打点延迟导致统计偏移。
- 打点必须放在
c.Next()之后、且在defer外显式执行，例如：httpReqCounter.WithLabelValues(c.Request.Method, c.FullPath(), strconv.Itoa(c.Writer.Status())).Inc() - 高频接口可提前缓存
WithLabelValues结果，比如按method+path组合存map，避免重复查找 - 确认Gin是否启用了
ReleaseMode（gin.SetMode(gin.ReleaseMode)），Debug模式的日志开销会拖慢实际QPS，让监控值虚低
CounterVec的生命周期、打点时机、PromQL查询方式，都得对得上真实业务流量节奏。 
