内存溢出需先定位代码而非盲目调高memory_limit，重点排查require、json_decode等操作，用memory_get_usage()和memory_get_peak_usage()插桩分析，注意CLI与Web模式差异及opcache、FPM配置影响。
内存溢出错误直接看 Allowed memory size exhausted
PHP 报这个错时，不是“可能”内存不够，而是 memory_limit 确实被突破了。关键不是盲目调高限制，而是先确认哪段代码在吃内存。错误堆栈里出现的 require、include、json_decode、file_get_contents 或循环中的 array_push 都是高频嫌疑点。
用 memory_get_usage() 和 memory_get_peak_usage() 定位热点
这两个函数不耗资源，适合插桩排查。区别在于：memory_get_usage(true) 返回当前分配的**总内存块大小**（含未释放的碎片），而 memory_get_peak_usage() 返回脚本运行至今的**内存峰值**——后者更反映真实压力。
echo "初始: " . memory_get_usage() . "\n";
$data = file_get_contents('/big-file.json');
echo "读完文件: " . memory_get_usage() . "\n";
$json = json_decode($data, true);
echo "解析后: " . memory_get_usage() . "\n";
echo "峰值: " . memory_get_peak_usage() . "\n";
- 如果
json_decode后内存暴涨几倍，说明结构嵌套太深或存在循环引用 - 如果
file_get_contents就占满内存，就得换流式处理（如fopen+fgets） - 注意：CLI 模式下默认
memory_limit常为-1（不限制），但 Web SAPI（如 Apache/FPM）通常设为128M或256M，行为不一致要留意
ini_set('memory_limit', '512M') 是临时补丁，不是解法
它只对当前请求生效，且不能高于 php.ini 中 memory_limit 的硬上限（除非你有权限改配置）。更危险的是掩盖问题：比如一个本该分页查库的接口，靠提内存硬扛 10 万条记录，下次数据翻倍就又崩。
- Web 场景优先检查
phpinfo()输出的memory_limit实际值，注意 FPM pool 级配置（php_admin_value[memory_limit]）会覆盖全局 - 大数组操作前加
unset($old_array)，别依赖 GC 自动回收——PHP 7.4+ 的 GC 对大数组响应仍滞后 - 对象实例避免在循环中反复 new，改用对象池或复用已有实例
启用 opcache.memory_consumption 反而可能加剧 OOM
OpCache 本身吃内存，尤其当 opcache.max_accelerated_files 设得过大，或大量动态生成文件（如 Twig 编译模板、Laravel 的 storage/framework/views）时，缓存区会快速占满。此时 memory_get_usage() 看不到 opcache 占用，但整体进程 RSS 会飙升。
立即学习“PHP免费学习笔记（深入）”；
- 用
opcache_get_status()查看memory_usage和interned_strings_usage -
开发环境建议关掉 opcache（
opcache.enable=0），避免干扰内存分析 - 生产环境若频繁重编译，说明
opcache.revalidate_freq太低，导致缓存失效后反复加载，不是内存不够，是配置不合理
pm.max_children 和单个 worker 的内存叠加效应——每个请求都逼近 memory_limit，10 个并发就能吃掉 2.5G 物理内存。这时候调单个 memory_limit 不解决问题，得看整体资源配比。 
