用 runtime.ReadMemStats 可获取精确堆内存快照，m.Alloc 表示活跃堆字节数，需传非 nil 指针，开销微秒级；NumGoroutine() 精确返回当前存活 goroutine 数，跳变常因泄漏；WriteHeapDump 抓取含栈帧的堆快照；手动 GC 会破坏自适应策略、引发 STW 和 GC storm，应避免。
如何用 runtime.ReadMemStats 获取实时内存快照
Go 程序的堆内存使用情况不能靠 top 或 ps 粗略判断，必须调用 runtime.ReadMemStats 才能拿到准确、一致的 GC 相关指标。它会阻塞当前 goroutine 直到统计完成，但开销极小（微秒级），适合周期性采集。
- 必须传入一个非 nil 的
*runtime.MemStats指针，否则 panic -
MemStats.Alloc是当前已分配且未被 GC 回收的字节数（即“活跃堆”），不是 RSS；TotalAlloc是累计分配总量，可用于观察内存泄漏趋势 - 注意：该函数不包含操作系统层面的内存（如 mmap 分配的栈、cgo 内存、runtime 自身元数据），这些需配合
/proc/PID/status查看
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("heap in use: %v KB\n", m.Alloc/1024)
为什么 runtime.NumGoroutine() 返回值突然跳变
runtime.NumGoroutine() 返回的是当前存活的 goroutine 总数，包括正在运行、就绪、阻塞（如 channel wait、syscall、time.Sleep）的所有 goroutine。它不是采样值，而是原子读取当前调度器状态，因此数值本身是精确的——但「突然跳变」往往暴露真实问题。
- 常见诱因：未回收的 HTTP handler goroutine（忘记 close response body 或 context 超时）、无限 for-select 循环未加退出条件、timer/ ticker 未 stop 导致底层 goroutine 泄漏
- 该函数调用开销极低，可安全用于健康检查接口，但不要在 hot path 频繁调用（比如每毫秒一次）
- 若发现数值持续缓慢上涨，应结合
debug/pprof/goroutine?debug=2查看完整栈，重点关注阻塞在select或chan receive的 goroutine
用 runtime/debug.WriteHeapDump 抓取带 goroutine 栈的堆快照
runtime/debug.WriteHeapDump（Go 1.19+）比传统 pprof 堆转储更轻量，且默认包含所有 goroutine 的当前栈帧和堆对象归属关系，适合排查「谁分配了大量小对象」或「某个 struct 被意外长期持有」。
- 输出是二进制格式，需用
go tool heapdump解析：go tool heapdump -stacks my.dump - 必须确保目标文件路径可写，且程序有足够权限创建文件；若写入失败，函数直接 panic，无错误返回
- 它不会触发 GC，所以抓到的是「此刻」的堆状态，适合在疑似泄漏点附近主动触发，而非依赖定时 dump
runtime.GC() 不该被手动调用的三个理由
显式调用 runtime.GC() 强制触发垃圾回收，看似能“立刻释放内存”，实则破坏 Go 运行时的自适应 GC 策略，通常有害无益。
立即学习“go语言免费学习笔记（深入）”；
- 它会 STW（Stop-The-World），暂停所有用户 goroutine，延迟不可控；而 Go 默认的 GC 触发时机（基于堆增长速率）已做充分优化
- 频繁调用反而导致 GC 周期紊乱，可能引发“GC storm”：刚回收完又因新分配快速触发下一轮，CPU 持续飙高
- 真正需要控制的是内存行为本身——比如复用
sync.Pool、避免逃逸、减少小对象分配，而不是干预 GC 时间点
唯一合理场景：测试中验证对象是否真被回收（配合 runtime.SetFinalizer），生产环境应彻底避免。
