PHP本地内存不足报错需分CLI和Web环境分别调整：先用php --ini和php -r确认配置路径及当前限制，CLI可临时加-d参数或修改对应php.ini，Web需改其专用php.ini或在入口文件用ini_set；注意Xdebug、旧版Composer等干扰因素。
PHP 本地环境内存限制设得太低，php -v 或运行 composer install、php artisan migrate 时直接报 Fatal error: Allowed memory size of XXX bytes exhausted，这不是代码问题，是配置没调对。
查清当前内存限制在哪生效
PHP 内存限制受多个层级控制，优先级从高到低：脚本内 ini_set('memory_limit', ...) → 命令行 -d memory_limit=... → php.ini 中的 memory_limit → Web 服务器（如 Apache/Nginx）加载的 php.ini 路径可能和 CLI 不同。
执行以下命令确认你实际在改哪个配置：
php --ini
再查当前生效值：
立即学习“PHP免费学习笔记（深入）”；
php -r "echo ini_get('memory_limit');"
如果输出 -1，说明不限制；如果是 128M 或 512M，就可能是瓶颈所在。
- CLI（命令行）和 Web 请求用的不是同一个
php.ini，php --ini显示的是 CLI 的路径，phpinfo()页面显示的是 Web 的路径 -
memory_limit设为-1在本地开发可接受，但上线必须禁用——仅限调试阶段 - 某些 Docker 镜像或 MAMP/XAMPP 会额外覆盖
php.ini，需检查Loaded Configuration File输出是否为你修改的文件
安全提升内存限制的三种方式
不建议全局无脑设成 -1，应按需分场景调整：
- Composer 安装/更新：运行前加参数，不影响其他命令
php -d memory_limit=-1 composer install - Laravel Artisan 命令：同样临时提升
php -d memory_limit=1G artisan migrate - 长期开发需要：修改 CLI 对应的
php.ini（路径见php --ini），找到memory_limit = 128M行，改为memory_limit = 512M或1G；改完必须重启终端（CLI 配置不热加载）
注意：1G 是合法写法，等价于 1024M；不要写 1000M 这类非 2 的幂次值，PHP 解析可能出偏差。
为什么调高了还是报错？检查这三点
内存耗尽未必是 PHP 自身限制导致，常见干扰项：
- Composer 使用了旧版
composer.phar，升级到最新版常能大幅降低内存占用：composer self-update - PHP 扩展冲突，比如
xdebug开启后内存开销翻倍。本地调试时可临时禁用：php -d zend_extension= -d memory_limit=-1 composer install - 某些框架（如 Laravel）在
config/app.php或服务提供者里做了递归加载、大数组预热，可在命令中加--no-interaction --quiet减少输出开销
用 ps aux | grep php 观察进程真实内存占用，排除系统级资源不足（尤其 Docker Desktop 默认只分 2GB 内存给 Linux 子系统）。
Web 请求内存限制要单独处理
你在 CLI 调高了内存，但浏览器访问 localhost 仍报错？那是因为 Web 服务器加载的是另一份 php.ini。定位方法：
在页面里搜索 Loaded Configuration File，编辑该路径下的 php.ini，改同一行 memory_limit。Apache 下改完需 sudo apachectl restart，Nginx + PHP-FPM 需重启 php-fpm 进程。
更稳妥的做法是，在入口文件（如 public/index.php）顶部加一行：
这样只影响 Web 请求，不污染 CLI 环境，也避免多人协作时因配置路径差异引发问题。
真正麻烦的不是“怎么调高”，而是“调高之后谁在偷偷吃内存”——
var_dump大对象、未关闭的数据库游标、Xdebug 的 full mode 日志、甚至 Composer 的autoload_classmap.php文件过大，都可能让 1G 也不够用。先用memory_get_usage(true)插桩定位峰值，再决定是否调参。
