Go微服务性能监控需聚焦延迟分布、资源水位、请求健康度三大问题：用HistogramVec按path/method/status打标并设业务适配buckets，避免Summary；运行时指标须用rate观察goroutines趋势，GC次数突增比耗时更早暴露内存泄漏；HTTP状态码需正确捕获，pprof必须限访问、控采样时长。
Go 微服务的性能监控不是“加个 metrics 就完事”，而是围绕 延迟分布、资源水位、请求健康度 三个真实问题展开——你得知道慢在哪、撑在哪、崩在哪。
用 HistogramVec 记录请求耗时，别用 Summary
很多人一上来就用 Summary 想直接拿到 P95/P99，结果发现指标不准、Prometheus 查询卡顿。根本原因是 Summary 在客户端做分位数计算，无法跨实例聚合；而 HistogramVec 把原始分布（bucket）暴露出去，Prometheus 用 histogram_quantile() 算才真正反映全量数据的真实延迟。
- 必须按
path、method、status打标，否则查“下单接口 P99”时会混入健康检查或静态资源请求 -
Buckets要贴合业务：电商下单建议设为[]float64{0.05, 0.1, 0.2, 0.5, 1.0, 3.0, 5.0}（单位秒），别直接抄默认DefBuckets——它从 10ms 开始，对后端 API 意义不大 - 中间件里打点前务必用
time.Since(start)，别用time.Now().Sub(start)，后者在系统时间跳变时可能返回负值，导致 Prometheus 拒绝该样本
暴露 Go 运行时指标要小心 goroutines 和 gc_last_time_seconds
默认注册的 promhttp.Handler() 会自动带上 go_goroutines、go_gc_duration_seconds 等指标，但它们容易误报问题：
-
go_goroutines瞬时值波动大（比如一次 HTTP 请求 spawn 几个 goroutine 处理 DB+Redis），单看曲线没意义；应改用rate(go_goroutines[5m])观察趋势，或配告警规则：go_goroutines > 5000 and rate(go_goroutines[5m]) > 0（持续增长才告警） -
go_gc_duration_seconds的quantile="0.5"是中位数，但 GC 延迟毛刺往往出现在尾部；更关键的是go_gc_duration_seconds_count——如果每分钟 GC 次数突增，大概率是内存泄漏，比看耗时更早发现问题 - 生产环境禁用
go_memstats_alloc_bytes的 raw 值，它包含未释放的临时对象；应关注rate(go_memstats_alloc_bytes_total[5m])（分配速率）和go_memstats_heap_inuse_bytes（实际占用）
HTTP 中间件打点时，状态码必须从 ResponseWriter 捕获，不能读 r.Context().Value()
常见错误是中间件里写了个自定义 responseWriter，但没重写 WriteHeader()，导致所有失败请求都记成 200。更隐蔽的问题是：Gin/Echo 等框架内部可能提前写 header，而你的中间件还在 handler 后才读状态——这时 w.Header().Get("Status") 已为空。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：包装
http.ResponseWriter，实现WriteHeader(int)并记录statusCode字段，再在 defer 里打点 - 别在中间件里调
http.Error()或panic()后继续执行，这会导致 status 被覆盖或重复打点 - 对 3xx 重定向请求，是否计入“成功”取决于业务——比如登录跳转应算成功，但 API 层的 302 重试则应归为异常，需统一约定并体现在 label 上（如加
redirect="true"）
pprof 不是“打开就行”，/debug/pprof/profile 必须带 seconds 参数
线上服务开 net/http/pprof 时，最常被忽略的是 CPU profile 默认采样 30 秒——这意味着你访问 /debug/pprof/profile 时，服务会卡住半分钟，且期间新请求可能堆积。这不是设计缺陷，而是防止误操作拖垮服务。
- 必须显式指定时长：
/debug/pprof/profile?seconds=30（最长建议 ≤15s），短时采样（如 5s）对定位瞬时毛刺更有效 -
/debug/pprof/heap的debug=1参数能显示每行代码的内存分配，但会显著增加内存开销；日常只用debug=0（汇总视图） - 生产环境必须限制访问：
http.ListenAndServe("127.0.0.1:6060", nil)，绝不要监听0.0.0.0；若需远程调试，走 SSH 端口转发，而非加 BasicAuth——pprof 本身不校验 auth，加了也白加
真正难的不是埋点，而是让每个指标都回答一个具体问题：这个 http_request_latency_seconds_bucket 是否能帮你判断“是不是缓存失效导致下单变慢”？那个 go_goroutines 是否真能让你在 OOM 前 5 分钟收到告警？指标一旦脱离问题场景，就只是噪音。
