最轻量可靠的方式是启动时在main()第一行调用runtime.ReadMemStats，获取Alloc、HeapAlloc、Sys等字段作为基准线，避免init中调用以防污染；pprof不适用于启动快照因采样失真且依赖GC完成。
直接看启动时的内存分配快照，runtime.ReadMemStats 是最轻量、最可靠的方式——它不触发 GC，只读取当前运行时状态，且开销极低（纳秒级 STW），适合在 main() 开头立即采集。
启动瞬间调用 runtime.ReadMemStats 的正确时机
Go 程序的“启动时”不是指 go run 命令敲下那一刻，而是指 runtime 初始化完成、用户代码开始执行的第一刻。此时：
- 所有标准库初始化已完成（如
net/http、fmt的包级变量已初始化） - 但业务逻辑尚未分配任何对象（比如还没
make([]byte, ...)或构造结构体） - 这个快照能作为后续内存增长的基准线（baseline）
实操建议：
- 把
runtime.ReadMemStats放在main()函数第一行，不要加time.Sleep或其他前置操作 - 避免在
init()函数里调用——部分包（如database/sql）可能在init中悄悄分配内存，污染 baseline - 用
fmt.Printf或日志输出关键字段，例如m.Alloc、m.HeapAlloc、m.Sys
runtime.ReadMemStats 返回字段中哪些真正反映“启动分配”
不是所有字段都适合做 baseline 对比。重点关注：
立即学习“go语言免费学习笔记（深入）”；
-
m.Alloc：当前堆上已分配且未释放的字节数 → 最核心指标，反映“活对象”内存占用 -
m.HeapAlloc：等价于Alloc，语义更明确，推荐优先用它 -
m.Sys：从操作系统申请的总内存（含 heap + stack + code + runtime metadata）→ 可看出 runtime 自身开销（通常 2–5 MiB） -
m.Mallocs：累计分配对象次数 → 配合Alloc能判断平均对象大小（比如Alloc / Mallocs ≈ 100B表明大量小对象）
注意：
-
m.TotalAlloc是累计值，启动时就非零（runtime 初始化本身会分配），不能当 baseline 用 -
m.HeapSys和m.Sys接近但不相等，差值通常是栈和 mmap 区域，启动时差异很小 -
m.NumGC == 0是理想状态；若不为 0，说明某些包的init触发了 GC（罕见但可能）
为什么不用 pprof.Lookup("heap").WriteTo 做启动快照
pprof.Lookup("heap") 输出的是堆对象的采样快照（基于逃逸分析 + 分配点统计），不是精确内存镜像：
- 它默认只记录“大对象”或高频分配路径，小对象（如
struct{}、短字符串）可能被采样率过滤掉 - 输出内容依赖 GC 是否已运行过 —— 启动时若
NumGC == 0，heap profile 可能为空或严重失真 - 文件体积大（几 MB）、写磁盘慢，不适合程序启动瞬时采集
结论：
- 要 baseline，用
ReadMemStats；要定位泄漏源，才用pprof.WriteHeap - 如果硬要用 pprof，必须先确保至少一次 GC 完成（比如加
runtime.GC()+time.Sleep(10ms)），但这已不是“启动时”了
启动快照本身不难，难的是后续对比。很多人记下 HeapAlloc = 2.3 MiB，然后运行一小时后看到 280 MiB 就 panic，却没意识到其中 200 MiB 来自缓存池或连接池预分配——这些是设计使然，不是泄漏。真正该盯的是 HeapAlloc 随请求量线性上涨的部分，而不是绝对数值。
