必须先用memory_get_usage(true)和memory_get_peak_usage(true)定位真实内存消耗点，再针对性调整memory_limit；盲目调大或修改max_execution_time等无关参数无效，且会掩盖泄漏、延迟问题定位。
先改 memory_limit，但必须配合实测确认——不是盲目调大，而是用 memory_get_usage(true) 和 memory_get_peak_usage(true) 找出真实吃内存的位置。
为什么不能直接改 max_execution_time 或其他参数
PHP 8.3 报错 “Allowed memory size exhausted” 时，max_execution_time、max_input_time 等参数完全不相关。它们管的是时间，不是内存。改了没用，还可能掩盖真正瓶颈。
常见误操作包括：
- 看到报错就去调
max_execution_time = 300，结果脚本卡在内存耗尽前就被 kill，错误信息反而变成 “Killed” 或 “Segmentation fault” - 以为
opcache.revalidate_freq影响内存占用，其实它只控制文件校验频率，和单次请求内存峰值无关 - 在
.htaccess里写php_value max_execution_time 300，却对 CLI 场景无效，白改
memory_limit 怎么改才有效
改之前先确认是否真超限，而不是代码泄漏或一次性加载过大数据：
PHP 8.5.12 RC 1
下载
PHP 8.5.12 RC 1 候选版修复 BZ2、DOM、PDO、Opcache/JIT 和扩展内存安全问题，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
- 在疑似高内存操作前后插点：
echo "Before: " . memory_get_usage(true) . "\n";，比如json_decode()大字符串、PDOStatement::fetchAll()、循环中拼接长字符串等位置 - 对比
memory_get_peak_usage(true)和ini_get('memory_limit')，单位都是字节；若前者接近后者（比如差 2–5MB），才是真瓶颈 - CLI 下优先用
php -d memory_limit=512M script.php临时覆盖，避免污染全局配置 - Web 场景改
php.ini时，确认是 FPM 实际加载的那个文件（php --ini或phpinfo()查路径），改完必须重启php-fpm，reload不生效
容易被忽略的静默失效点
memory_limit 配置看似简单，但以下情况会让它“设了等于没设”：
-
disable_functions里禁了ini_set，脚本内ini_set('memory_limit', '1G')直接被忽略，不报错也不生效 - 云函数、共享主机、Docker 容器镜像可能在启动时硬编码内存上限（如 cgroup limit），此时
php.ini和ini_set全部无效 - Windows 下
php.ini路径写错（比如用了php.ini-production而非php.ini-development），扩展没启用，memory_get_usage()返回值不准，误判 - 某些框架（如 Laravel）在
bootstrap/app.php早期就初始化大量服务，ini_set()写在后面已来不及——必须放在<?php后第一行
最危险的是把 memory_limit 设成 -1 就以为万事大吉。PHP 8.3 下 OOM 往往不是因为上限太低，而是某处对象引用没释放、PDO 没 closeCursor()、递归没出口，或者 JSON 解码后没 unset 大数组。调大只是延缓爆炸，不解决根本问题。
