Composer install/update 报错“Allowed memory size exhausted”是因PHP默认memory_limit不足，解决方法包括临时提升内存限制（如php -d memory_limit=-1 composer install）、优先用install代替update、禁用插件（--no-plugins）等。
Composer install/update 报错 Allowed memory size exhausted
这是 Composer 在解析依赖或下载包时，PHP 内存耗尽导致的典型错误，常见于 Laravel 项目或大型依赖树。根本原因不是 Composer 本身内存管理差，而是 PHP 默认的 memory_limit（通常为 128M 或 256M）不够用——尤其当 composer update 需要计算数百个包的版本兼容性时，内存峰值很容易突破 1G。
临时提高 PHP 内存限制（推荐用于单次操作）
不改全局配置，只对当前命令生效，安全且可逆：
- Linux/macOS：运行
php -d memory_limit=-1 /usr/bin/composer install（-1表示无限制；路径请替换成你本地composer实际位置，可用which composer查） - Windows：运行
php -d memory_limit=-1 C:\path\to\composer.phar install - 如果用的是 Composer 2.2+，还可直接加
--memory-limit=-1参数：composer install --memory-limit=-1
注意：memory_limit=-1 在生产环境绝对不要设为永久值，仅限本地开发或 CI 临时突破瓶颈。
避免触发高内存场景的实操技巧
很多情况下，问题不在于“内存不够”，而在于“Composer 在干没必要干的重活”：
- 用
composer install代替composer update—— 只要项目有有效的composer.lock，就绝不该在部署或日常开发中跑update - 删掉
vendor/后执行install前，先确认composer.lock是最新且未被手动修改过；否则 Composer 会重新解析整个依赖图 - 禁用插件可显著降内存：加
--no-plugins参数，尤其当你没用到hirak/prestissimo或自定义插件时 - 跳过平台检查（仅调试用）：
--ignore-platform-reqs有时能绕过因 PHP 扩展缺失引发的反复回溯计算
为什么改 php.ini 不是首选方案
全局调高 memory_limit 看似一劳永逸，但实际埋雷：
- CI 环境（如 GitHub Actions）里改
php.ini需额外步骤，不如直接传参干净 - 多个项目共用一个 PHP 实例时，某项目因 Composer 占满内存，可能影响其他 Web 请求（比如 Apache 下的 PHP-FPM 子进程）
- 某些共享主机禁止修改
php.ini，或仅允许通过.user.ini，但该文件对 CLI 模式无效
真正需要长期调整的，是 Composer 的缓存和并行行为（比如用 composer config -g repos.packagist.org.allow_ssl_downloads false 加速国内源），而不是硬顶内存上限。
