PHP进程被kill -9的直接原因是Linux OOM Killer干预，而非PHP memory_limit超限；需检查dmesg日志确认，并调大vm.overcommit_memory和vm.overcommit_ratio，同时容器中优先检查内存限制配置。
PHP 进程被 kill -9 终止，memory_limit 设置无效？
直接原因往往是系统级 OOM Killer 干预，而非 PHP 自身报 Fatal error: Allowed memory size exhausted。此时改 php.ini 里的 memory_limit 没用——进程在到达 PHP 内存限制前就被 Linux 内核强制杀死了。
验证方式：查系统日志：dmesg -T | grep -i "killed process"，若看到类似 Killed process 12345 (php) total-vm:2048000kB, anon-rss:1800000kB，就是 OOM Killer 下的手。
- 必须同步调大
/proc/sys/vm/overcommit_memory（建议设为1）和/proc/sys/vm/overcommit_ratio（如80），否则内核仍可能拒绝分配 -
memory_limit建议设为明确值（如512M），避免用-1—— 它不绕过 OOM，反而让 PHP 更晚触发内存释放逻辑，更容易撞上内核限制 - 容器环境（Docker/K8s）需额外检查
--memory或resources.limits.memory，它比memory_limit优先级更高
大数组遍历或 ORM 全量查询导致内存暴涨
典型场景：用 foreach ($pdo->query('SELECT * FROM huge_table')->fetchAll() 一次性拉取百万行；或 Laravel 的 Model::get() 直接返回全部模型实例。每行数据在 PHP 中会生成独立 zval、对象、关联数组，内存占用常达原始 SQL 结果的 5–10 倍。
关键不是“怎么读得更快”，而是“怎么不让全量进内存”：
立即学习“PHP免费学习笔记（深入）”；
- 用游标式分页替代
LIMIT offset, size：MySQL 用WHERE id > ? ORDER BY id LIMIT 1000，避免OFFSET越大越慢 + 全表扫描 - PDO 开启
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false，配合while ($row = $stmt->fetch())流式读取，但注意：事务中不能复用同一连接做其他查询 - Laravel 用
chunkById(1000, function ($users) { ... })，它底层自动处理 ID 断点，比chunk()更稳定（后者依赖ORDER BY字段唯一性）
临时变量未及时 unset() 或引用未清除
PHP 的垃圾回收（GC）不是实时的，尤其涉及循环引用（如对象属性互相持有）时，unset() 是最可控的释放手段。常见陷阱：
- 在长循环中累积构建数组：
$allData[] = $row;—— 必须在每批处理完后unset($allData)，不能只靠作用域结束 - 使用
static变量或全局缓存（如$GLOBALS['cache']）存储中间结果，忘记清空 - 闭包捕获了大变量：
$bigArray = [...]; $handler = function() use ($bigArray) { ... };—— 即使闭包只用一次，$bigArray生命周期也会延长到闭包销毁
调试技巧：循环中插入 echo memory_get_usage(true), "\n";，确认峰值是否随迭代线性增长 —— 若是，大概率有变量未释放。
分批逻辑里隐含的内存泄漏点
分批本身不保安全，错误实现反而更耗内存。例如：
for ($i = 0; $i < $total; $i += $size) {
$batch = Model::skip($i)->take($size)->get(); // ❌ 每次都 new 新模型实例，旧批次对象未释放
process($batch);
}正确做法要切断引用链：
- 用
DB::table('xxx')->select(...)->chunkById($size, $callback)，Laravel 会自动释放每批模型 - 手动分批时，在
process($batch)结束后立刻unset($batch)，且确保process内部不长期持有引用（如写入静态数组） - 避免在分批循环内创建新 PDO 实例、重复 include 大文件、或反复
json_decode(file_get_contents(...))
最易被忽略的是：分批处理中调用的第三方 SDK（如 AWS S3 客户端、Elasticsearch 客户端）内部可能缓存连接或响应体，需查阅其文档确认是否支持显式 close() 或设置 http_options 限制缓冲区大小。
