memory_get_peak_usage(true) 是查看 php 内存峰值最直接有效的方式，需在 symfony 事件回调、orm flush 前后等关键路径埋点，传 true 才能统计含空闲块的总堆分配量，真实反映 oom 风险。
用 memory_get_peak_usage(true) 在关键位置埋点
只在入口文件开头结尾调用 memory_get_peak_usage(true)，会漏掉中间件、ORM flush、事件监听器这些真正吃内存的环节。比如 Symfony 的 kernel.request 和 kernel.terminate 事件回调里必须各记一次；Doctrine 的 EntityManager::flush() 前后也得分别调用——否则你根本发现不了写入放大导致的内存陡增。
别放在 __destruct 或 register_shutdown_function 里：GC 触发不可控，数值常比实际低 20%～40%，尤其在 worker 模式下，失真更严重。
为什么必须传 true 参数
不带参数或传 false 时，memory_get_peak_usage() 只统计 PHP 堆上“已用”内存，忽略底层已分配但空闲的内存块；而传 true 会统计整个进程堆总分配量（含空闲块），这才是 Linux OOM Killer 真正盯上的数字。
FrankenPHP Worker 模式下，一次小泄漏可能到第 100 个请求才爆发，但峰值内存从第一个请求起就在爬升——只有 true 模式能提前暴露这种渐进式风险。
记录时机要避开冷启动和 GC 干扰
首次请求常因 OPcache 加载、类自动注册等产生虚高峰值，建议跳过前 3 个请求再开始记录；同时避免在 gc_collect_cycles() 后立刻取值，它会强制回收一部分内存，让峰值读数偏低。
推荐组合：
- 在请求进入框架路由前（如 Caddy 的
php_server回调中）取一次初值 - 在响应即将写出前（如 Symfony 的
kernel.response事件）再取一次终值 - 两者差值才是本次请求真实新增内存压力，比单点峰值更有定位价值
别把 memory_get_usage() 当峰值用
memory_get_usage() 返回的是当前已用内存，不是历史最大值；它在长生命周期 worker 中几乎恒定（比如稳定在 8MB），完全看不出泄漏趋势。只有 memory_get_peak_usage(true) 才能反映“这个 worker 自启动以来最高冲到多少”。
更关键的是：它不包含 OPcache 共享内存、ZEND 全局结构、Go 主进程开销——所以你在日志里看到 12MB，实际 ps 查 RSS 可能是 65MB。真要看系统级压力，得配合 ps -o pid,rss,comm -p $(pgrep -f "frankenphp-worker") 定期采样。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
