将 memory_limit 设为 -1 只是临时缓解，因为它移除了 php 脚本层面的内存上限，但并未触及操作系统内核的进程地址空间限制（rlimit_as），一旦脚本进入死循环或处理超大输入，仍会触发 oom killer 导致整个进程崩溃。相比之下，直接修改 rlimit_as 极其危险，因为它是硬性资源限制，若设置不当或遭遇突发流量峰值，会导致关键服务进程被系统强制终止且无法恢复，从而引发严重的可用性事故。
为什么 memory_limit = -1 只是治标不治本？
在 PHP-FPM 环境中，memory_limit 是 PHP 解释器内部的软性限制。将其设为 -1 意味着 PHP 不再检查自身分配的内存是否超标，而是直接向操作系统申请。这种做法能暂时解决因复杂算法或大数组导致的 "Allowed memory size exhausted" 错误，但它没有改变操作系统对单个进程的内存配额。如果代码中存在逻辑漏洞（如无限递归或未释放引用），PHP 进程会持续消耗内存直到耗尽宿主机的物理内存或 Swap，最终由 Linux 内核的 OOM Killer 介入杀死进程。此时，虽然 PHP 层面没有抛出异常，但服务已经不可用，且重启后的默认配置可能再次触发问题，因此这仅是绕过报错而非修复根源。
php -r '
ini_set("memory_limit", "-1");
$data = str_repeat("x", 1024 * 1024 * 50); // 尝试分配 50MB
$big_array = array_fill(0, 1000000, $data);
// 实际运行中，若系统内存不足，此处不会报 PHP 错误，
// 而是直接导致进程被 OOM Killer 终止。
'
预期结果：无 PHP Fatal error，进程状态变为 D (uninterruptible sleep) 或直接退出，系统日志出现 Out of memory: Kill process'
RLIMIT_AS 为何被视为高危操作？
RLIMIT_AS 是 Linux 内核提供的虚拟内存限制，它控制进程可寻址的总空间大小。与 PHP 的 memory_limit 不同，RLIMIT_AS 是硬性的系统级约束。在生产环境中，如果为了安全而调低 RLIMIT_AS，一旦遇到合法的内存高峰（如批量导出、图像处理），进程会立即收到 ENOMEM 错误或信号终止，且由于这是内核级别的拒绝，PHP 无法通过 catch 异常来优雅降级。更危险的是，如果管理员误将 RLIMIT_AS 设置为极小值或 0，或者在多租户共享宿主机时未隔离好，任何一个微小的内存泄漏都可能导致核心业务进程被瞬间杀死，造成服务雪崩。此外，现代 PHP 扩展（如 Zend OPcache）和底层库往往需要预留额外的内存空间，过紧的 RLIMIT_AS 会导致非预期的崩溃，其排查难度远高于普通的 PHP 内存溢出。
# 查看当前 shell 的 RLIMIT_AS (单位通常为 KB)
ulimit -v
# 尝试设置一个极小的值进行测试 (危险操作，仅限测试环境)
# ulimit -v 10240 # 限制为 10MB
# php -r 'echo ini_get("memory_limit");'
预期结果：若 RLIMIT_AS 小于 PHP 启动所需的最小内存，php 命令将无法启动，返回 "Cannot allocate memory" 错误，且无任何 PHP 日志输出
基于程序中某个输入、条件或结果的具体问题
当程序接收到一个包含数百万条记录的 CSV 文件作为输入，并试图将其全部加载到关联数组中进行处理时，即使 memory_limit 设为 -1 且 RLIMIT_AS 充足，程序也会因 GC（垃圾回收）压力过大而导致 CPU 飙升和响应超时。这是因为 PHP 的变量容器（zval）在存储大量数据时会占用远超数据本身大小的元数据空间。正确的做法不是放宽限制，而是改用生成器（Generator）或流式读取（fgetcsv）逐行处理，确保内存占用恒定在低位。这种输入条件下的具体表现是：内存曲线呈阶梯状上升而非线性增长，且在达到阈值前会出现明显的延迟抖动。
