Histogram的P99不准根本原因是Buckets未覆盖真实延迟分布，导致histogram_quantile()插值失效；应按SLA目标（如P99≤200ms）或指数增长（如ExponentialBuckets(0.001,2,12)）精细设桶，而非用DefBuckets。
为什么 Histogram 的 P99 总是 0 或不准
根本原因不是采样少，而是 Buckets 设置没覆盖真实耗时分布。Prometheus 的 Histogram 不是实时计算分位数，而是把每个观测值塞进预设桶里计数，最后靠 histogram_quantile() 插值得到 P99——如果所有请求都落在最后一个桶外，插值就退化成该桶上限，结果恒为常量。
- 别用
prometheus.DefBuckets：它从 10ms 开始，最大只到 10s，对毫秒级服务完全失效 - 按 SLA 目标设桶：比如要求 P99 ≤ 200ms，至少得覆盖
[]float64{0.05, 0.1, 0.2, 0.5}（单位秒） - 高频服务建议用指数桶：
prometheus.ExponentialBuckets(0.001, 2, 12)（1ms 起，翻倍到 ~2s） - 调用
Observe()必须在 handler 正常/panic/超时所有路径都执行，漏一条就会让分母失真
CounterVec 和 GaugeVec 的 label 值精度怎么控
label 值不是“精度”问题，而是 cardinality（基数）爆炸的导火索。一个带 user_id 的 CounterVec，每新增一个用户就多一条时间序列，10 万用户 = 10 万序列，Prometheus 存储和查询直接崩。
- 路径必须归一化：
/order/12345→/order/{id}，用框架的路由模板（如 Gin 的c.FullPath()）而非c.Request.URL.Path - 禁止用动态业务 ID 打标；改用分类维度，例如错误类型只取
timeout、db_error、network三个合法值 - 标签名全小写+下划线：
tenant_id✅，TenantID❌，tenant-id❌（会 panic） - 传参顺序必须和
NewCounterVec(..., []string{"method", "endpoint", "status"})声明严格一致，否则WithLabelValues("GET", "/api/v1/users", "500")会 panic
指标注册时机影响“有效精度”
注册晚了，等于指标从服务启动后某时刻才开始采集，前面所有请求的耗时、状态码全丢——这不是数值精度低，而是时间窗口精度被砍掉一大截。
-
MustRegister()必须在http.ListenAndServe()之前完成，不能放在 handler 或中间件里 - 运行时指标也要显式注册：
prometheus.MustRegister(prometheus.NewGoCollector())，否则go_goroutines、go_memstats_alloc_bytes压根不出现 - 用自定义
prometheus.NewRegistry()时，promhttp.HandlerFor(reg, ...)的reg必须和注册指标的是同一个实例 - 多个包初始化同名指标会 panic：
duplicate metrics collector registration attempted，中大型项目务必统一 registry + 手动注册
Content-Type 和响应格式错一个字，精度就归零
Prometheus 抓取失败不会报“精度低”，而是直接跳过这个 target，日志里只有一句 server returned HTTP status 200 OK; expected 200 OK with content type "text/plain"。你看到 /metrics 返回 200，但 Prometheus 拉不到任何数据。
-
promhttp.Handler()已废弃，必须用promhttp.HandlerFor(prometheus.DefaultRegisterer, promhttp.HandlerOpts{}) - 禁用所有中间件拦截
/metrics：gzip、auth、log、cors 都会污染Content-Type: text/plain; version=0.0.4 - 若用 Gin，别写
router.Use(authMiddleware)后再挂/metrics，应单独起 mux 或用router.GET("/metrics", gin.WrapH(...))并确保无前置中间件 - 防火墙或反向代理（如 Nginx）若重写路径或加 header，也会导致抓取失败
真正卡住精度的，从来不是浮点数舍入误差，而是桶没盖住实际延迟、label 塞进了用户 ID、注册拖到服务跑起来之后、或者 Content-Type 被中间件悄悄改掉——这些地方一错，指标就不是“不准”，而是“根本不存在”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
