修改 php.ini 中的 memory_limit 是唯一可靠方式，php 8.5 未新增内存限制机制，运行时 ini_set 受限于 disable_functions 或扩展禁用，且需在报错前执行并重启 php 进程生效。
php.ini 里改 memory_limit 是唯一可靠方式
PHP 8.5 没有新增内存限制机制，memory_limit 仍由 php.ini 控制，运行时用 ini_set('memory_limit', ...) 只在脚本启动后生效，且受 disable_functions 或 Suhosin 等扩展限制，多数生产环境已被禁用。
常见错误现象：Fatal error: Allowed memory size of XXX bytes exhausted 出现后临时加 ini_set 却没效果——大概率是被禁了，或放在报错代码之后执行。
- 改 php.ini 前先确认加载的是哪个文件：
php --ini或phpinfo()查Loaded Configuration File - 值支持单位：数字+
K/M/G（如256M），-1表示不限（不推荐线上用） - CLI 和 Web SAPI 的配置文件可能不同，
php -i | grep 'Configuration File'分别查 - 改完必须重启 PHP 进程（FPM reload、Apache restart 等），仅刷新页面无效
为什么 memory_limit 设太高反而容易出问题
不是越大越好。PHP 进程内存超限时，Linux OOM Killer 可能直接 kill 掉整个 php-fpm worker，比脚本报错更难排查；另外高内存设置会掩盖真正的内存泄漏或低效算法问题。
典型使用场景：处理大 Excel（PhpSpreadsheet）、批量图像压缩、递归解析深层嵌套 JSON —— 这些操作本身吃内存，但调到 1G 以上前，先确认是否真需要全量加载。
立即学习“PHP免费学习笔记（深入）”；
- 用
memory_get_usage(true)查当前实际分配的内存块大小，比memory_get_usage()更准 - 配合
gc_collect_cycles()主动触发垃圾回收，尤其在循环中反复 new 对象时 - 如果只是偶尔超限，优先考虑流式处理（如用
fgetcsv替代file_get_contents+str_getcsv）
PHP-FPM 下每个 worker 的内存是独立计算的
memory_limit 是 per-request 限制，不是全局总和。一个 pm.max_children = 10 的 FPM 池，即使设 memory_limit=512M，理论上峰值内存可能达 5G，但实际取决于并发请求数和每个请求的真实消耗。
容易踩的坑：监控只看服务器总内存使用率，发现“才用了 60%”就盲目调高 memory_limit，结果某次流量突增，大量 worker 同时接近上限，触发 OOM。
- 用
php-fpm -t && systemctl reload php-fpm确保配置语法正确再 reload - 观察
slowlog和access.log中响应时间长 + 内存飙升的请求，针对性优化而非全局提限 - 容器环境注意 cgroup 内存限制（如 Docker
--memory）可能比memory_limit更早触发 kill
CLI 脚本的 memory_limit 默认值经常被忽略
CLI 模式下默认值通常是 -1（不限），但很多团队统一用 web 配置覆盖 CLI，导致跑批脚本突然失败。而 php -d memory_limit=512M script.php 这种命令行覆盖方式，容易被 shell 脚本或 crontab 忘记写。
真实调试场景：用 symfony/console 写的命令，在本地跑通，上生产就爆内存——八成是 CLI php.ini 跟 FPM 不一致。
- 检查
php -r "echo ini_get('memory_limit');"输出，确认 CLI 当前值 - 不要依赖
.htaccess或ini_set改 CLI 脚本，它们根本不起作用 - 在脚本开头加
if (ini_get('memory_limit') 提前报错
真正麻烦的从来不是改哪个配置项，而是改完之后没人盯着 memory_get_peak_usage() 的变化趋势——它比错误日志更早暴露设计缺陷。
