Go语言无开箱即用的通用性能自检模块，但可用runtime.ReadMemStats（关注HeapAlloc/Sys比值）、debug.ReadGCStats（查PauseQuantiles和NumGC）、debug.Stack（过滤goroutine阻塞态）组合构建轻量自检接口，支持按需健康检查并返回扁平JSON。
Go 语言里没有现成的“通用性能自检模块”开箱即用，但用 runtime、debug 和标准库的 net/http/pprof 组合，配合轻量级指标采集逻辑，就能在几小时内搭出稳定、低侵入、可扩展的自检能力——关键是别把监控和自检混为一谈，自检要快、要本地、要能被健康探针直接调用。
用 runtime.ReadMemStats 获取实时内存水位，而不是依赖 GC 日志
很多人想从 GC 日志解析堆增长趋势，但日志异步、延迟高、格式不稳定。真正可靠的内存自检，应直接读取运行时内存快照：
-
runtime.ReadMemStats是同步调用，开销极低（微秒级），返回的是当前精确的堆分配、系统内存、GC 次数等字段 - 重点关注
MemStats.HeapAlloc（已分配但未释放的字节数）和MemStats.Sys（Go 向 OS 申请的总内存），二者比值持续 > 0.85 就值得告警 - 避免反复 new
runtime.MemStats{}—— 直接传地址：var ms runtime.MemStats; runtime.ReadMemStats(&ms) - 不要在高频 goroutine 中每秒调用多次；建议 10–30 秒采样一次，或只在 /health 端点被访问时触发
用 debug.ReadGCStats 判断 GC 是否失控，而非只看频率
GC 频率高不等于有问题，关键看每次 GC 是否真回收了内存。靠 debug.ReadGCStats 查最近 200 次 GC 的真实效果：
- 检查
GCStats.NumGC增长是否异常快（比如 1 分钟内 > 100 次），再结合LastGC时间戳判断是否密集抖动 - 更关键的是看
GCStats.PauseQuantiles—— 如果第 99 百分位暂停时间 > 5ms，说明 GC 开始影响响应延迟 - 注意：
debug.ReadGCStats返回的是历史统计，不是实时事件；它不阻塞，但数据有约 200 次 GC 的窗口限制 - 别用
runtime.GC()强制触发来“清理”——这会干扰正常 GC 调度，反而加剧抖动
暴露自检结果为 JSON HTTP 接口，不走 pprof 或 Prometheus 格式
自检模块的核心是供运维脚本、K8s liveness probe 或 SRE 工具快速判断“能不能继续收请求”，不是做长期指标存储。所以接口设计要简单直接：
立即学习“go语言免费学习笔记（深入）”；
- 路径用
/health?check=mem,gc,goroutines，支持按需指定检查项，避免全量采集拖慢探针 - 响应体是扁平 JSON，例如：
{"ok":true,"mem_ok":true,"gc_pause_ms_99":3.2,"goroutines":47} - HTTP 状态码严格遵循：全部通过返回 200；任一子项失败（如 heap alloc > 80% limit）返回 503；解析错误或 panic 返回 500
- 禁止在该接口里调用外部服务、查 DB 或写磁盘——所有数据必须来自内存快照或 runtime 接口
goroutine 泄漏检测不能只数总数，得结合状态过滤
runtime.NumGoroutine() 单看数字意义不大，1000 个 goroutine 可能全是 idle worker，也可能全是卡在 channel send。真正的泄漏信号藏在状态分布里：
- 用
debug.Stack()抓当前所有 goroutine 的 stack trace，然后正则匹配常见阻塞模式："chan send"、"semacquire"、"selectgo" - 对每个 trace 做哈希归类，统计重复栈最深的前 3 类——如果某类占比 > 30% 且数量持续上升，大概率是泄漏点
- 生产环境慎用 full stack dump（可能上 MB）；建议加限流：只在
GOROUTINE_CHECK=1环境变量开启，且单次最多采样 200 个 goroutine - 别依赖
pprof/goroutine?debug=2输出——它不带 timestamp，无法做趋势比对
真正难的不是采集数据，而是定义“异常”的边界：内存多少算高？GC 多久算长？这些阈值必须随服务实际负载动态调整，硬编码的 80% 或 5ms 往往误报。上线前至少拿压测流量跑 24 小时，用真实 P95 堆内存和 GC 暂停作为基线再设告警线。
