memory_get_peak_usage(true) 是查看 PHP 内存峰值最直接有效的方式，它统计进程堆总分配量（含空闲块），真实反映 OOM 风险；需在关键路径如事件回调、ORM 操作、大文件处理处埋点，并结合 ini_get('memory_limit') 换算后做比例告警（如 >75%）。
memory_get_peak_usage(true) 是查看 PHP 代码内存峰值最直接有效的方式，它返回当前请求（或 worker 生命周期）中实际分配过的最大内存量（字节数），比 memory_get_usage() 更能反映真实压力点。
为什么必须加 true 参数
不带参数或传 false 时，memory_get_peak_usage() 只统计 PHP 堆上“已用”内存，忽略底层未释放但已被标记为可复用的内存块；而传 true 会统计整个进程堆的总分配量（含空闲块），这才是 OOM 风险的真实依据。FrankenPHP Worker 模式下尤其关键——一次泄漏可能在第 100 个请求才暴露，但峰值内存从第一个请求起就在悄悄爬升。
在哪打点才不会漏掉关键路径
仅在入口文件（如 public/index.php）开头结尾调用，会漏掉中间件、事件监听器、ORM 查询等重负载环节。建议按以下位置埋点：
- 在 Symfony 的
kernel.request和kernel.terminate事件回调里分别记录起始和结束峰值 - 在 Doctrine
EntityManager::flush()前后各调一次，定位写入放大问题 - 对大文件上传、Excel 导出等高内存操作函数，包裹在
try块内并在finally中记录峰值 - 避免放在
__destruct或register_shutdown_function中——GC 触发时机不可控，数值失真
怎么把峰值和 memory_limit 对齐看
光看数字没意义，得结合当前限制做比例判断：
立即学习“PHP免费学习笔记（深入）”；
- 先用
ini_get('memory_limit')获取配置值，注意单位可能是M、G或-1（不限制） - 手动换算成字节：
$limit = intval(ini_get('memory_limit')) * 1024 * 1024（仅适用于128M类格式；若为-1，跳过比例告警） - 当
memory_get_peak_usage(true) > 0.75 * $limit时，就该查日志或触发监控告警了——FrankenPHP 不会自动 kill，但 Linux OOM Killer 可能已经盯上你 - 别依赖
get_cfg_var('memory_limit')，它在某些 SAPI 下返回空
Worker 模式下，单次请求的峰值可能不高，但多个请求累积的“驻留内存基线”会缓慢抬升，所以一定要在 max_requests 重启前抓一次全生命周期峰值，否则永远发现不了缓存未清理这类渐进式泄漏。
