PHP 内存溢出（Fatal error: Allowed memory size of X bytes exhausted）首先看两点：报错发生在哪个脚本、哪一行，以及当时的内存上限是多少。排查时先定位是单次大内存操作（如读取大文件、查询大结果集）还是循环累积（如数组不断追加、递归过深），再决定是调高 memory_limit 还是改代码。调高上限只是临时缓解，长期解决要减少峰值内存占用，否则并发上来后仍会溢出。
遇到 PHP 内存溢出，先别急着改 memory_limit。用报错行号定位内存消耗点，结合 memory_get_peak_usage 确认峰值，区分单次大分配和循环累积。临时调高上限可救急，但根治要靠分批处理、流式读取、及时释放大变量。若峰值接近上限且业务确实需要大内存，再评估是否调整 php.ini 并观察并发下的稳定性。
先定位：报错行和内存峰值
PHP 的 OOM 报错通常会给出文件路径和行号，这是最直接的线索。如果行号指向一个简单的数组赋值或函数调用，内存很可能是在之前循环中累积起来的。此时在可疑代码段前后插入 memory_get_peak_usage(true) 打印峰值，可以判断内存是在哪一段快速上涨。
echo 'before: ' . memory_get_peak_usage(true) . PHP_EOL;
// 可疑代码
$data = $stmt->fetchAll();
echo 'after: ' . memory_get_peak_usage(true) . PHP_EOL;如果峰值在 fetchAll 之后陡增，问题就在结果集一次性加载；如果峰值在循环中逐步上升，则要检查数组是否只增不减、对象引用是否未释放。对于 CLI 脚本，还可以用 /usr/bin/time -v php script.php 观察整体内存曲线。
常见内存消耗点与处理动作
- 数据库大结果集：用 fetchAll 一次性取回大量行会直接撑爆内存。改为逐行 fetch 或分页查询，并避免在循环中把每行追加到数组。
- 大文件读取：file_get_contents 读大文件会整块载入内存。改用 fopen + fgets 流式读取，或 SplFileObject 逐行处理。
- 循环内累积数组：在循环中不断 $arr[] = $row 且不释放，内存线性增长。若只需聚合结果，边循环边计算，不保留原始数据；必须保留时考虑分批写入临时存储。
- 递归过深：递归函数每层都保留局部变量，深度大时内存快速上升。改为迭代实现，或限制递归深度。
- 字符串拼接：在循环中用 .= 拼接超大字符串可能产生多份副本。改用数组收集后 implode，或写入临时流。
处理顺序建议：先改代码减少峰值，再评估是否调整 memory_limit。如果业务确实需要一次性加载较大数据（如图片处理、PDF 生成），在确认并发量可控的前提下，适当调高 memory_limit 并配合 max_execution_time 调整，同时监控实际峰值。
调整 memory_limit 的边界
memory_limit 可以在 php.ini、.htaccess 或运行时用 ini_set 调整。运行时 ini_set('memory_limit', '512M') 只对当前请求有效，适合临时救急；php.ini 修改影响全局，需重启 PHP-FPM。注意 CLI 和 FPM 的配置可能不同，用 php -i | grep memory_limit 和 phpinfo() 分别确认。
调高上限前要问：峰值内存是否随数据量线性增长？如果是，调高只是推迟溢出，数据再大仍会出问题。只有峰值相对固定、且业务逻辑无法拆分时，调高上限才是合理选择。调整后观察一段时间的内存峰值和 FPM 进程内存占用，避免单个进程吃掉过多内存影响并发。
验证清单
- 报错行号对应的代码是否涉及大数组、大文件或大查询？
- 用 memory_get_peak_usage(true) 确认峰值出现在哪一段，是否接近 memory_limit？
- 循环中是否有只增不减的数组或未释放的大对象？
- 数据库查询是否用了 fetchAll 且结果集很大？能否改为逐行或分页？
- 文件读取是否用了 file_get_contents？能否改为流式读取？
- 调整 memory_limit 后，峰值是否仍随数据量增长？若是，继续改代码而非继续调高。
完成代码修改后，用相同数据量复测峰值内存，确认峰值明显下降且不再触发 OOM。若必须保留较高 memory_limit，记录调整原因和监控指标，便于后续排查。