热路径监控必须用 runtime/metrics 而非 pprof；它零分配、纳秒级开销、支持高频聚合采样，配合 rate() 才能识别 goroutine 持续增长或分配速率突增等真实风险。
热路径监控必须用 runtime/metrics 而非 pprof
pprof 是诊断工具，不是监控手段；它采样开销大、无法高频采集、不支持聚合，拿它盯热路径等于用显微镜看流水线——看得清单点，但漏掉趋势。真正适合热路径持续监控的是 runtime/metrics 包，它零分配、纳秒级开销、每秒可读取多次，且指标语义明确（如 /sched/goroutines:goroutines、/gc/heap/allocs:bytes）。
常见错误是把 debug.ReadGCStats() 或 runtime.NumGoroutine() 当主力指标：前者要锁全局，后者只是瞬时快照，无法反映变化率。而 runtime/metrics 返回的是带时间戳的样本流，配合 rate() 才能识别“goroutine 持续增长”或“分配速率突增”这类真实风险。
- 启动时调用
runtime/metrics.SetProfileRate(100)（非必须，仅影响 GC 栈采样精度） - 用
runtime/metrics.Read()每 5–10 秒批量读取，别用 goroutine 频繁轮询（避免自身成热路径） - 重点关注：
/sched/goroutines:goroutines（趋势）、/gc/heap/allocs:bytes（分配速率）、/gc/heap/frees:bytes（释放速率）、/memory/classes/heap/objects:bytes（对象堆占比） - 避免读取
/gc/heap/allocs:bytes的 raw 值——它会随 GC 波动剧烈，应计算rate(gc_heap_allocs_bytes_total[1m])
HTTP 热路径需按 method+path+status 分桶打点
只记“总请求耗时”对热路径毫无意义：一个慢的 /healthz 掩盖了 /api/v1/order 的毛刺，而 400 错误请求的延迟又不该和 200 混在一起统计。必须用 HistogramVec，标签维度至少包含 method、path、status，且 buckets 要贴合业务 SLA。
例如电商下单接口，prometheus.HistogramOpts.Buckets 设为 []float64{0.05, 0.1, 0.2, 0.5, 1.0, 3.0, 5.0}，而不是默认的 DefBuckets（从 10ms 开始，对后端 API 完全失焦）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 中间件中务必用
time.Since(start)计算耗时，time.Now().Sub(start)在系统时间跳变时可能返回负值，导致 Prometheus 拒绝该样本 - status 必须从
ResponseWriter实际写入值获取，不能依赖r.Context().Value()—— Gin/Echo 等框架可能提前写 header，你的中间件若在 handler 后才读，会漏掉 5xx - path 标签要标准化：把
/user/123/profile归一为/user/:id/profile，否则 label 组合爆炸，Prometheus 存储和查询都崩
数据库与下游调用热路径必须显式透传 context 并包装 client
热路径常卡在 DB 查询或下游 HTTP 调用，但若没做适配，这些调用在指标里就只剩一个黑洞：你看到 HTTP handler 耗时 800ms，却不知道其中 750ms 花在 db.QueryRowContext() 上。根本原因是 Go 的 context 不自动跨 goroutine，也不自动注入 tracing span。
必须手动 wrap：DB 用 otelmysql.Wrap(db) 或 otelpostgresql.Wrap(db)；HTTP client 用 otelhttp.NewClient() 实例，并确保每次请求都调用 req = req.WithContext(ctx)；异步任务必须写成 go doWork(ctx)，而非 go doWork(context.Background())。
- 漏掉
otel.SetTracerProvider(tp)—— 所有Tracer().Start()返回空 span，日志和指标里完全没链路，还不报错 - gRPC 调用必须用
otelgrpc.UnaryClientInterceptor，自己解析traceparentheader 会丢 span name 和 error 属性 - 不要用原生
sql.Open后再套 wrapper：有些 driver（如 pgx）内部会新建 goroutine，若未传 ctx，span 就断在 driver 层
热路径告警阈值不能固定，得结合 rate 和 delta
设个 “耗时 > 500ms 就告警” 是无效的：凌晨低峰期 200ms 算异常，大促期间 800ms 可能仍达标。热路径告警必须基于变化率或偏离基线，而非绝对值。
例如：对 http_request_duration_seconds_bucket{path="/api/v1/order",le="0.5"}，用 1 - rate(http_request_duration_seconds_bucket{path="/api/v1/order",le="0.5"}[5m]) / rate(http_request_duration_seconds_count{path="/api/v1/order"}[5m]) 计算当前 P50 超过 500ms 的比例；再对比过去 7 天同时间段的中位数，偏差超 3 倍才触发。
- goroutine 告警别盯
go_goroutines当前值——它每秒波动几百是常态；改用rate(go_goroutines[5m]) > 50（5 分钟内每秒新增超 50 个） - 内存泄漏早期信号是
go_gc_duration_seconds_count每分钟突增，比go_memstats_heap_inuse_bytes上涨早 2–3 个 GC 周期 - 所有热路径指标必须加
job和instance标签，否则无法区分是单实例抖动还是全局问题
热路径监控最难的不是采集，而是让每个环节的指标能对齐到同一语义层级：runtime 指标反映资源水位，HTTP histogram 反映请求健康度，OpenTelemetry span 反映调用链路。三者时间戳、标签、采样逻辑若不统一，查问题时就会在不同面板间反复横跳，最后发现根本不是同一个请求。
