内存溢出错误是PHP主动终止执行的致命错误，非异常故try/catch无法捕获；真正问题在于此前数十至数百行的内存持续累积，需用memory_get_peak_usage(true)定位峰值压力点，配合关键节点打点分析循环、大对象、数据库查询等高开销操作。
这个错误不是异常，try/catch 捕获不到，脚本会直接中断。它只说明：当前脚本已用内存逼近或超过 memory_limit 配置值，PHP 主动终止执行——但真正的问题往往不在报错那行，而在前面几十行甚至几百行的内存积累过程。
为什么 memory_get_usage() 和 memory_get_peak_usage() 要配合用
单看 memory_get_usage() 只能知道当前占用，容易误判；memory_get_peak_usage(true) 才反映脚本生命周期中内存使用的峰值，更贴近溢出真实压力点。尤其在循环、大对象构建、PDO fetchAll() 后，峰值可能远高于当前值。
- 在数据库查询后立刻打点：
echo "after query: " . memory_get_peak_usage(true) . "\n"; - 在循环体内外各打一次，对比增长量，确认是否循环内持续累积（比如每次迭代都 new 一个大对象且没 unset）
-
true参数表示返回格式化字节数（含单位），false返回原始整数，调试时建议用true - 注意：这些函数本身也占少量内存，高频调用（如每轮循环都调）反而干扰判断，建议关键节点控制在 5–10 次以内
哪些操作最容易触发 Allowed memory size exhausted
不是所有“大”操作都等价。有些看似轻量，实则暗藏高内存开销：
-
file_get_contents()读取 >2MB 的文件：整个内容一次性进内存，不如用fopen()+fgets()流式读取 -
PDO::fetchAll()或mysqli_fetch_all()拉取数千行以上结果：每行数据都会生成数组副本，建议改用fetch()迭代处理 -
json_encode($huge_array)：编码过程会复制原数组结构，若 $huge_array 已占 80M，编码时可能瞬时冲到 120M+ -
var_dump()/print_r()输出大型对象或数组：不仅输出缓冲区膨胀，Xdebug 开启时还会深度展开引用，极易假性溢出 - 未清理的全局缓存变量，比如在长生命周期脚本中反复
$cache[] = $data;却从不unset()或清空
临时绕过和长期修复的区别在哪
临时调高 memory_limit 是最常见动作，但必须清楚它解决的是表象，而非根源。真正有效的修复，是让脚本在默认 128M 下也能稳住。
立即学习“PHP免费学习笔记（深入）”；
- 修改配置优先级：
php.ini>.htaccess（Apache）>ini_set('memory_limit', '256M')（代码内），但后者在disable_functions含ini_set时失效 - WordPress 用户可在
wp-config.php加define('WP_MEMORY_LIMIT', '256M');，比改 php.ini 更安全，不影响其他站点 - 流式替代方案比调高上限更可持续：比如用
yield构建生成器处理大数据集，或用SplFixedArray替代普通数组降低约 30% 内存开销 - 检查
get_included_files()返回数量，若超 150 个，大概率存在自动加载失控或重复 require，应排查 Composer autoload 或框架路由机制
最常被忽略的一点：错误日志里显示的文件名和行号，90% 不是内存增长的起点，而是压垮骆驼的最后一根稻草。真正的泄漏点往往藏在上层逻辑里——比如一个被反复调用的工厂方法悄悄累积了 100 个未释放的 Doctrine Entity 实例。定位它，靠的不是加内存，而是打点 + 对比 + 剥离测试。
