memory_limit 设置不生效的常见原因包括：CLI 与 Web 环境使用不同 php.ini；FPM 中 php_admin_value 强制覆盖；htaccess 在 FPM/CGI 下无效；ini_set 只能调大不能调小且受 disable_functions 限制；内存统计不含 C 扩展等底层分配；-1 无限制易致 OOM；单位大小写敏感（如 128mb 解析为 0）。
memory_limit 设置不生效的常见原因
PHP 脚本实际内存使用超出 memory_limit 却没报错，大概率不是配置写错了，而是配置没落到当前运行环境上。CLI 和 Web（如 Apache/FPM）用的是两套独立的 php.ini，改了 Apache 的 php.ini 对 php -v 或命令行脚本完全无效。
- 查当前生效配置：运行
php -i | grep memory_limit（CLI）或在 Web 环境中写<?php phpinfo(); ?>搜索memory_limit行 - FPM 场景下，
php-fpm.conf或 pool 配置里可能用php_admin_value[memory_limit]强制覆盖php.ini，此时改php.ini无效 -
.htaccess中的php_value memory_limit在 CGI/FPM 模式下被禁用，Apache + mod_php 才支持
ini_set('memory_limit') 在什么情况下能用
ini_set('memory_limit', '128M') 看似方便，但它受 safe_mode（已废弃）和 disable_functions 影响，更重要的是：它只能设得比当前限制「更大」，不能调小——哪怕你只是想临时收紧某段逻辑的内存上限。
- 若原
memory_limit是-1（无限制），ini_set可设为任意正数值；但若已是128M，再ini_set('memory_limit', '64M')会静默失败，ini_get('memory_limit')仍返回128M - 该函数只对当前请求生命周期有效，无法跨请求或影响子进程（比如
exec()启动的外部命令） - 某些 SAPI（如嵌入式 PHP）可能完全禁用运行时修改
内存爆掉前根本没触发 fatal error？检查 real usage
PHP 报 Fatal error: Allowed memory size of X bytes exhausted 前，实际内存占用可能早已远超 memory_limit。因为 PHP 的内存统计是「向 Zend 引擎申请的内存量」，而 C 扩展、OPcache、PCRE 缓存、甚至某些系统调用分配的内存并不计入其中。
- 用
memory_get_peak_usage(true)查当前脚本真实峰值（含未释放的底层分配），比memory_get_usage(true)更反映压力 - 开启
opcache.memory_consumption会额外占用固定内存，且不参与memory_limit计算 - 大数组或对象循环引用导致 GC 无法及时回收时，
memory_limit往往在 GC 触发前就已突破
生产环境慎用 -1（无限制）的真正风险
把 memory_limit = -1 当成“一劳永逸”，结果可能是进程吃光服务器内存后被 OOM Killer 杀掉，连错误日志都来不及写。这不是 PHP 层能捕获的异常，Web 服务直接 502/504，排查时只剩系统日志里的 Out of memory: Kill process php-fpm。
立即学习“PHP免费学习笔记（深入）”；
- 容器环境（Docker/K8s）中，
memory_limit = -1会无视 cgroup 限制，导致容器被强制终止 - FPM 下每个 worker 进程独立计费内存，设太高容易因单个慢请求拖垮整个 pool
- 替代方案：按业务分层设限——CLI 脚本可略宽（如 512M），API 接口建议严格（64M–128M），后台任务单独配 pool 并限流
最常被忽略的一点：memory_limit 是每个请求的硬上限，但它的单位（M/G）和大小写敏感（128m 合法，128M 也合法，但 128mb 会变成 0），拼错一个字母就等于没设。
