快速定位内存泄漏需用 memory_get_usage(true) 和 memory_get_peak_usage(true) 打点监测，避免 array_merge 复制、foreach 值拷贝、PDO 全量加载；大文件/数据应流式处理、分页查询、直接写磁盘；unset 与 gc_collect_cycles() 配合可延缓 OOM，__destruct 和 gc_disable() 基本无效；CLI 设 memory_limit=-1 不安全，须设合理上限并拆分子进程。
PHP 脚本执行中 Allowed memory size exhausted 怎么快速定位内存泄漏点
直接看 memory_get_usage(true) 和 memory_get_peak_usage(true)，别靠猜。前者返回当前已分配的内存（含未释放的），后者返回脚本运行至今的内存峰值。在关键逻辑前后打点，比如循环开始前、每次迭代后、函数调用前后，用 echo sprintf("Mem: %s KB\n", memory_get_usage(true) / 1024); 输出，能立刻暴露哪段代码“只进不出”。
常见陷阱包括：array_merge 在大数组上反复调用会隐式复制整份数据；foreach ($hugeArray as $item) 默认是值拷贝，改用 foreach ($hugeArray as &$item)（注意后续 unset 引用）；PDO 查询未设 PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false 时，fetchAll() 会把全部结果集加载进内存。
大文件处理或批量任务中如何避免 memory_limit 溢出
核心原则：不把整个数据集 load 到内存里。读文件用 fopen + fgets 流式逐行处理；查数据库用游标式分页（LIMIT offset, size 配合递增 id 条件），而不是 SELECT * FROM huge_table 后用 PHP 分页；导出 CSV 时直接 fputcsv($fp, $row) 写磁盘，别先拼成一个超长字符串再 file_put_contents。
必要时主动释放：
unset($bigArray); gc_collect_cycles();注意
gc_collect_cycles() 并非万能——它只回收环形引用，对普通变量失效；但配合 unset 使用，在长生命周期脚本（如 CLI 批处理）中能延缓 OOM。
__destruct 和 gc_disable() 对内存释放到底有没有用
绝大多数情况下没用，甚至有害。__destruct 是对象销毁时回调，但 PHP 的垃圾回收本身不依赖它；手动调 gc_disable() 反而会让环形引用堆积，更早触发内存耗尽。真正有效的是减少对象创建频次、复用对象实例、避免闭包捕获大变量（use ($hugeData) 会让闭包持有一份副本）。
立即学习“PHP免费学习笔记（深入）”；
典型反模式：
$data = file_get_contents('1GB.log');
$lines = explode("\n", $data); // 立刻占两倍内存
foreach ($lines as $line) {
process($line);
} 正确做法是删掉 $data 和 $lines，用 fopen + while (($line = fgets($fp)) !== false) 流式处理，内存占用稳定在几 KB。
CLI 模式下 memory_limit 设为 -1 是不是就安全了
不是。设为 -1 只是关闭 PHP 层限制，但操作系统仍会 kill 掉耗尽物理内存或 swap 的进程（Linux 报 Killed process，无 PHP 错误提示）。更危险的是掩盖问题——你以为脚本跑通了，其实只是把内存压力转嫁给系统，可能拖垮其他服务。
务实做法：
- 用
ini_set('memory_limit', '256M')显式设合理上限（比默认 128M 略高） - 监控
memory_get_peak_usage()，超过阈值（如 200M）就抛异常或切分任务 - 对超大任务拆成多个子进程（
proc_open或shell_exec('php worker.php --batch=1 &')），让 OS 自动调度内存
