php内存溢出是zend致命错误，无法catch或事后清理，必须在逼近memory_limit时主动干预；需用memory_get_usage()监控、gc_collect_cycles()回收、及时unset/关闭资源，并避免fetchall()等内存累积操作。
报错后无法释放内存，只能预防和中断前干预
PHP 内存溢出（Fatal error: Allowed memory size of XXX bytes exhausted）是 Zend 引擎触发的致命错误，**不是异常，不能 catch，也无法在报错后执行任何清理逻辑**。所谓“报错后释放内存”本身不成立——进程已终止，变量、资源全被系统回收。真正要做的，是在内存逼近 memory_limit 时主动干预，或在关键路径上避免内存持续累积。
用 memory_get_usage() 和 memory_get_peak_usage() 打点监控
别等报错才行动。在循环入口、大查询之后、文件读取前/后插入内存快照，确认是否真增长：
echo "before loop: " . memory_get_usage() . "\n";
foreach ($rows as $row) {
process($row);
if (memory_get_usage() > 0.8 * $limit) { // 比如 limit=512M，到400M就预警
gc_collect_cycles(); // 强制运行垃圾回收
break;
}
}
echo "peak usage: " . memory_get_peak_usage() . "\n";
-
memory_get_usage(true)返回当前实际分配的内存块大小（含未释放的碎片） -
memory_get_peak_usage(true)是脚本运行至今的最高水位，比当前值更有参考价值 - CLI 下可设
gc_enable()并周期调用gc_collect_cycles()，尤其在长循环中
常见内存卡点及对应释放动作
很多“内存没释放”其实是变量还活着，或资源句柄没关：
- 数据库结果集：用
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false禁用缓冲，或改用fetch()迭代而非fetchAll() - 大数组处理完立刻
unset($huge_array)，但注意：这仅解除引用，真实释放依赖 GC；若需立即生效，跟gc_collect_cycles() - 文件句柄：
fopen()后必须配对fclose()，漏掉会导致底层 file descriptor + buffer 一直占着 - 对象循环引用：PHP 7.4+ 可用
WeakReference::create($obj)替代强引用；旧版本需手动在生命周期末尾置$obj->parent = null断链
ini_set('memory_limit') 不是释放，是拖延
在脚本里调 ini_set('memory_limit', '1G') 只会把崩溃点往后推，如果内存使用是线性增长（比如每轮循环多占 1MB），那只是多跑几百轮而已。更危险的是掩盖了真实问题：
- 查百万行却
fetchAll()到内存 → 改用流式 fetch 或分页 -
file_get_contents()读 GB 日志 → 改fopen()+fgets()行级流读 - 递归无深控 → 改迭代 + 显式栈，或加
if ($depth > 100) throw new RuntimeException('too deep');
真正难处理的，是那些不显眼但持续微增的引用——比如日志对象被闭包捕获、事件监听器没解绑、或者 ORM 实体在循环中不断 new 却没 unset。这些得靠 get_included_files() 和 xdebug_get_function_stack()（关闭 xdebug mode 后再测）交叉验证。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
