gin默认recovery中间件会破坏/metrics抓取，因其在panic时返回500且日志混杂难定位；应隔离监控路由、禁用中间件或启用独立http.server监听9091端口。
直接暴露 /metrics 端点就能撑起基础大屏，但真要稳定可用，得绕开默认中间件的 panic 捕获和日志干扰 —— 否则 Prometheus 抓取时可能被 500 或超时中断。
为什么 Gin 默认 Recovery 中间件会破坏 /metrics 抓取
Prometheus 抓取 /metrics 是高频、无状态的 HTTP GET 请求，而 Gin 的 gin.Recovery() 在 panic 时会写入响应体并返回 500。一旦指标注册逻辑（比如 promauto.NewCounterVec）触发了未预期 panic（如重复注册同名指标），整个抓取就失败，且错误日志混在业务日志里难定位。
- 避免全局启用
gin.Recovery()，改用路由组隔离：对监控端点单独创建 router 实例，不挂载 Recovery - 若必须共用 router，用
r.NoRoute()+r.NoMethod()替代 Recovery 处理兜底，但不要在/metrics路径上触发 - 检查所有
promauto.New*调用是否发生在init()或main()早期 —— 运行时重复调用会 panic
如何让 promhttp.Handler 不被 Gin 日志中间件污染
promhttp.Handler() 返回的是标准 http.Handler，而 Gin 的 gin.Logger() 会对每个请求打日志，包括 /metrics。每秒一次抓取就会产生大量冗余日志，还可能因日志 I/O 拖慢响应。
- 不用
r.GET("/metrics", gin.WrapH(promhttp.Handler()))—— 这会让请求经过完整 Gin 中间件链 - 正确做法是用
r.Any("/metrics", gin.WrapH(promhttp.Handler()))并确保该路由前没有Use()全局中间件 - 更干净的方式：启动独立的
http.Server监听另一个端口（如:9091），只跑promhttp.Handler()，完全脱离 Gin 生命周期
Gin 中注册自定义指标时容易踩的命名坑
Prometheus 对指标名和 label 有严格校验，Gin 路由参数（如 :id）若直接塞进 label 值，会导致非法字符（如斜杠、点号）引发注册失败或抓取异常。
- 别写
httpRequestsTotal.WithLabelValues(c.Request.Method, c.Param("path"), status)——c.Param("path")可能含/user/123，这不是合法 label value - 应提前规整：用
strings.ReplaceAll(c.FullPath(), "/", "_")或固定路径模板（如"user_detail"）代替原始路径 - label 名称必须符合正则
[a-zA-Z_][a-zA-Z0-9_]*，值不能含控制字符或空格；建议统一用pathlabel 存规整后的路由标识，而非原始 URL
轻量大屏前端怎么安全拉取指标数据
浏览器直连 /metrics 端点存在跨域和认证风险，Prometheus 官方也不推荐前端直接解析文本格式指标 —— 容易因格式微变（如注释、空行）导致解析失败。
- 不要用
fetch("/metrics")解析 raw text；改用 Prometheus 的/api/v1/query或/api/v1/query_range（需部署 Prometheus Server） - 若无 Prometheus Server，可在 Gin 中加一个简单代理接口，如
GET /api/metrics，内部调用http.Get("http://localhost:9091/metrics")，再 JSON 化关键指标（如http_requests_total{method="GET"}最新值） - 务必限制该代理接口的访问频率（如用
golang.org/x/time/rate），避免被刷爆
真正麻烦的不是注册几个 Counter，而是指标生命周期和 HTTP 生命周期耦合后产生的隐性冲突 —— 比如热更新时重复注册、goroutine 泄漏导致 Histogram bucket 内存持续增长、label 维度爆炸让 Prometheus server OOM。这些不会报错，但会让大屏数据慢慢失真。
