Go程序需组合标准库工具实现实时监控：用net/http/pprof查运行时指标（如CPU、内存、goroutine、GC），用expvar暴露自定义变量，用prometheus/client_golang对接Prometheus+Grafana实现可视化，三者用途不同不可混用。
Go 程序本身不内置环境监控界面，要实时查看系统状态（CPU、内存、goroutine 数、GC 情况等），得靠组合标准库 + 外部工具，而不是“配置一个监控工具”就完事。
用 net/http/pprof 查看运行时指标
这是最轻量、最常用的方式，无需第三方依赖，Go 标准库自带。它暴露的不是图形界面，而是可被 go tool pprof 解析的原始数据端点。
- 在主程序中注册：
import _ "net/http/pprof" // 然后启动 HTTP 服务（哪怕只监听 localhost） go http.ListenAndServe("localhost:6060", nil) - 关键端点：
-
/debug/pprof/：索引页，列出所有可用 profile 类型 -
/debug/pprof/goroutine?debug=1：当前 goroutine 堆栈（文本） -
/debug/pprof/heap?debug=1：堆内存摘要（含 topN 分配者） -
/debug/pprof/gc：最近 GC 的时间戳和暂停时间
-
- 注意：
?debug=1返回纯文本；不带参数则返回二进制 profile 数据（供go tool pprof使用） - 别在生产环境直接暴露
localhost:6060到公网——它没有认证机制
用 expvar 暴露自定义变量与运行时统计
expvar 提供了简单的键值式指标导出，适合暴露应用层计数器（如请求总数、错误数）、内存缓存大小等，它默认挂载在 /debug/vars。
- 自动注册的变量包括：
cmdline、memstats（来自runtime.ReadMemStats）、num_goroutine - 添加自定义变量：
import "expvar" var reqCount = expvar.NewInt("http_requests_total") // 每次请求递增 reqCount.Add(1) - 返回 JSON，可直接被 Prometheus 的
expvar_exporter抓取，也方便 curl 调试：curl http://localhost:6060/debug/vars | jq '.num_goroutine' - 不能动态删除已注册变量；变量名冲突会 panic，建议用命名空间前缀（如
myapp_http_requests_total）
对接 Prometheus + Grafana 实现可视化
单独用 pprof 或 expvar 只能查快照，要“实时查看”，必须引入指标采集与展示链路。
立即学习“go语言免费学习笔记（深入）”；
- 选
prometheus/client_golang替代expvar：支持 Counter/Gauge/Histogram，有标签（label）能力，更适配 Prometheus 模型 - 暴露 metrics endpoint（如
/metrics）：import ( "github.com/prometheus/client_golang/prometheus/promhttp" ) http.Handle("/metrics", promhttp.Handler()) - Prometheus server 配置 job 抓取该地址；Grafana 添加 Prometheus 数据源后，就能建面板显示 goroutines、heap_alloc、http_request_duration_seconds_sum 等
- 注意：不要把
/debug/pprof和/metrics混用——前者是诊断用的 profiling 数据，后者是聚合指标，用途和采样频率都不同
避免常见误操作
很多人以为加个包就能“开箱即用”，结果卡在权限、路径或语义误解上。
- 在容器中运行时，
localhost不等于宿主机可访问 —— 启动服务需绑定:6060或0.0.0.0:6060，并检查容器端口是否映射 -
runtime.NumGoroutine()返回的是瞬时数量，不是峰值；pprof/goroutine?debug=1里的 “running” 状态 goroutine 才代表真正在执行，其余多为阻塞或休眠 - 用
go tool pprof http://localhost:6060/debug/pprof/heap时，若提示 “no samples”，说明程序还没触发 GC 或分配足够内存——可手动调用runtime.GC()触发一次 - 不要在热代码路径里频繁调用
runtime.ReadMemStats—— 它会 STW（stop-the-world），影响延迟
真正难的不是加几行代码，而是区分清楚：哪些数据用于故障定位（pprof），哪些用于趋势观测（Prometheus），哪些只是调试快照（expvar）。混用它们，反而会让监控变成噪音源。
