memory_limit不是防火墙，仅是资源配额开关，无法防御恶意攻击；应分级设限（如Web请求≤512M）、配合输入拦截、分块处理与显式释放，并重视PHP-FPM、Docker及云平台的内存硬约束。
memory_limit不是防火墙，它只管用量不管来源
PHP的memory_limit根本不是为防“攻击”设计的，它只是个资源配额开关。恶意构造的递归、无限循环或超大数组确实能触发Allowed memory size of X bytes exhausted错误，但这属于资源耗尽而非传统意义的内存溢出攻击（如C语言堆栈溢出）。真正该防的是：用户上传超大文件后被file_get_contents()全量加载、表单提交嵌套过深的JSON导致json_decode()爆内存、或通过API批量请求触发未分页的全表查询。
设成-1或2G真能防住？反而更危险
生产环境把memory_limit设为-1或盲目调高到2G，等于主动放弃最后一道资源闸门。一旦代码存在未修复的内存泄漏（比如PDOStatement没调closeCursor()、对象循环引用没打断），脚本会持续吃内存直到OOM Killer干掉整个PHP-FPM worker进程，连带其他正常请求一起挂掉。
- CLI任务可临时设
-1，但必须配合memory_get_peak_usage()监控并校验实际用量 - Web请求建议硬上限≤512M，且需按场景分级：普通页面
128M、Excel导出384M、图像处理512M - PHP-FPM池级配置
process.memory_limit比脚本里ini_set()更可靠，后者可能被禁用
真正有效的三道防线
光调memory_limit是治标。必须组合落地：
-
输入层拦截：Nginx用
client_max_body_size限制POST体大小，PHP里用$_SERVER['CONTENT_LENGTH']在$_POST解析前就拒绝超限请求 -
处理层分块：数据库查大表必须用游标分页（
WHERE id > ? LIMIT 1000），读大文件必须用fopen()+fgets()，别碰file_get_contents() -
释放层显式清理：PDO操作完立刻
$stmt->closeCursor()，大数组处理完立刻unset($bigArray)，对象解引用时清空parent和children属性
容易被忽略的硬约束点
很多人以为改了php.ini里的memory_limit就万事大吉，却忘了这些地方同样起作用且优先级更高：
立即学习“PHP免费学习笔记（深入）”；
- PHP-FPM pool配置里的
php_admin_value[memory_limit]——它会直接屏蔽ini_set()调用 - Docker容器的
--memory限制，如果容器内存上限是1G，PHP设再高也白搭 - 云平台（如AWS Lambda、阿里云函数）的执行内存配额，PHP配置再大也越不过平台限制
