memprofilerate需结合采集时机与差分分析才能准确定位内存泄漏：设0则无采样数据，设1导致性能崩溃；生产推荐1024–4096且仅在main开头设一次；必须通过两次相隔30–60秒的heap快照差分（用inuse_space增量）识别真实泄漏。
MemProfileRate 不是“调得越低越准”，而是必须结合采集时机和差分逻辑才能定位真实泄漏点。
MemProfileRate 设为 0 或 1 的后果很直接
设成 0：采样完全关闭，pprof.WriteHeapProfile 写出的文件非空但内容为空（只有 header），别被文档里“全量采集”误导——Go 早已移除该能力；
设成 1：每字节分配都记录调用栈，内存和 CPU 开销暴涨，线上服务可能卡死，本地调试也仅限极短时间、单 goroutine 场景；
常见误操作：
- 在 HTTP handler 里动态改
runtime.MemProfileRate，导致采样状态错乱（运行时只认最后一次设置）； - 启动后多次赋值，比如 init → main → signal handler 各设一次，实际生效的是最后一次，且中间可能漏采；
- 用
GODEBUG=memprofilerate=1跑线上服务，没几分钟就 OOM。
生产环境推荐值：1024–4096，不是 512
默认 512（即 512KB）适合开发机跑小负载，但对高吞吐服务意味着每秒几十到上百次采样，容易掩盖小对象泄漏（比如每次分配 32B 的 map key）；
设成 1024 或 2048 后，采样频次减半或降至 1/4，CPU 占用稳定在 0.1% 以内，同时仍能捕获中等生命周期对象的累积趋势；
关键约束：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须在
main函数最开头设置，且只设一次； - 不要依赖
init函数，某些包初始化早于 runtime 设置，会导致部分分配未被覆盖； - 若程序有预热阶段（如加载配置、建连接池），建议在预热完成后再触发首次快照，避免噪声干扰。
真正有用的不是单次采样率，而是多时间点差分
内存泄漏的本质是“增长”，单张 heap profile 图看不出增长，只能看绝对占用；
正确做法是：
- 用 SIGUSR2 或 HTTP
/debug/pprof/heap端点，在相隔 30–60 秒后连续抓两次快照（如heap1.pb.gz和heap2.pb.gz）； - 用 pprof 差分命令：
go tool pprof -base heap1.pb.gz heap2.pb.gz，它会自动过滤掉不变的部分，只显示净增长对象； - 重点关注
inuse_space增量大的调用栈，而非alloc_space（后者包含已释放对象，干扰判断）； - 如果差分后仍无明显热点，说明泄漏对象太小或生命周期太短，此时才考虑临时下调
MemProfileRate到 256 或 128，但务必限定在测试环境且持续时间 ≤ 10 秒。
WriteHeapProfile 导出时机比采样率更关键
pprof.WriteHeapProfile 写出的是上一次 GC 完成后的快照，不是实时堆状态；
所以导出前务必确保 GC 已触发，否则可能拿到过期数据；
稳妥做法：
- 导出前手动调用
runtime.GC()并等待完成（加time.Sleep(100 * time.Millisecond)避免调度延迟）； - 或者监听
debug.ReadGCStats，确认NumGC增长后再导出； - 避免在高并发写入高峰期执行，否则
WriteHeapProfile本身会阻塞调度器约几毫秒，可能引发请求堆积。
采样率只是控制“记多少”，而泄漏是否能被发现，取决于你有没有在对的时间点记下对的两笔账。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
