应使用 runtime.ReadMemStats 获取 Go 程序实时活跃堆内存，m.Alloc 表示当前未回收字节数，m.TotalAlloc 用于检测泄漏；NumGoroutine() 配合 /debug/pprof/goroutine?debug=2 和 WriteHeapDump 可定位 goroutine 泄漏；GOMAXPROCS 默认即可，云环境需按容器 CPU 限制显式设置。
怎么安全获取实时堆内存使用量
别信 top 或 ps 显示的 RSS —— 那不是 Go 程序真正“活”着的堆大小。runtime.ReadMemStats 才是唯一靠谱的入口，它返回的是 GC 视角下精确的活跃对象字节数。
- 必须传非 nil 的
*runtime.MemStats指针，否则直接 panic -
m.Alloc是当前未被回收的堆内存（即“活跃堆”），单位字节；m.TotalAlloc是累计分配总量，适合画趋势图查泄漏 - 它不包含 mmap 分配的栈、cgo 内存、runtime 元数据——这些得看
/proc/PID/status的VmRSS和MMAP字段 - 调用开销极小（微秒级），但别在每毫秒都跑一次；健康检查接口里每秒调一次完全没问题
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("heap in use: %v KB\n", m.Alloc/1024)
goroutine 数突然飙升，怎么定位真凶
runtime.NumGoroutine() 返回值本身没毛病，跳变就是问题信号。它统计所有存活 goroutine：运行中、就绪、阻塞在 channel、syscall、time.Sleep 的全算。
- 典型泄漏场景：
http.Handler里忘了resp.Body.Close()或没设context.WithTimeout；无限for { select { ... } }缺退出条件；time.Ticker创建后没Stop() - 数值缓慢上涨？立刻访问
/debug/pprof/goroutine?debug=2，重点搜chan receive、select、syscall阻塞态 - 别只看数量——结合
debug.WriteHeapDump抓快照，再用go tool heapdump -stacks my.dump查哪个 goroutine 在疯狂 new 小对象
GOMAXPROCS 设多少才合理
默认值是系统逻辑 CPU 数（runtime.NumCPU()），绝大多数服务保持默认即可。强行设小（比如 1）不仅不会“省资源”，反而容易卡死。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 设为 1 时，如果主 goroutine 紧循环不 yield，其他 goroutine 可能永远得不到调度（连
runtime.Gosched()都救不了，除非手动插） - 设得过大（远超物理核数）会导致上下文切换增多、GC 停顿变长，尤其在高并发 I/O 场景下更明显
- 云环境注意：容器限制了 CPU quota（如
cpu.shares或cpusets），但runtime.NumCPU()仍读宿主机核数——这时应通过GOMAXPROCS环境变量或启动时显式设置，避免过度并行
什么时候该用 WriteHeapDump 而不是 pprof
当你需要「带完整 goroutine 栈帧的堆快照」时，runtime/debug.WriteHeapDump（Go 1.19+）比 pprof 更轻、更直接——它不触发 GC，也不依赖 HTTP 接口，适合嵌入关键路径主动 dump。
立即学习“go语言免费学习笔记（深入）”；
- pprof 堆采样是概率性的，且默认不含 goroutine 栈；
WriteHeapDump默认就记录每个堆对象归属哪个 goroutine 的哪一行代码 - 文件路径必须可写，权限不足或磁盘满会直接 panic，无错误返回——务必包
os.IsPermission或os.IsNotExist判断 - 别定时 dump：它抓的是“此刻”状态，应在疑似泄漏点附近（比如某个 handler 返回前）手动触发
NumGoroutine 上涨 + ReadMemStats 中 TotalAlloc 持续走高 + WriteHeapDump 显示某 struct 被几百个 goroutine 同时 hold 住——这三个信号凑齐，基本就能锁死泄漏源头。 
