Composer install 内存耗尽需优先用 php -d memory_limit=-1 composer install 临时解决，同时检查 PHP 版本与配置、升级 Composer 至 2.2.0+，并配合 --no-dev、--prefer-dist 等参数优化流程。
Composer install 时提示 Allowed memory size exhausted
这是 Composer 在解析依赖或解压包时 PHP 内存耗尽的典型表现，不是 Composer 本身的问题，而是 PHP 运行时内存限制太低。默认 memory_limit 常为 128M 或 256M，而现代项目（尤其含 Laravel、Symfony 等大框架）很容易突破这个阈值。
最直接有效的办法是临时提高 PHP 内存上限，但要注意：必须让 Composer 实际运行时生效，而不是只改了 php.ini 却没被 CLI 使用到。
- 优先用
php -d memory_limit=-1 composer install——-1表示无限制，适用于调试和 CI 环境 - 若报错仍出现，说明系统可能用了不同 PHP 版本，先确认：
which php和php -v，再检查该 PHP 对应的php.ini路径（php --ini） - 不建议永久把
memory_limit设为-1，生产环境应设为1G或2G并监控实际使用
为什么 COMPOSER_MEMORY_LIMIT 环境变量有时无效
这个环境变量是 Composer 自己识别的开关，但它只在 Composer 启动阶段读取，且优先级低于 PHP 的 memory_limit 设置。如果 PHP 层已因 memory_limit=128M 中断，Composer 根本没机会执行到读取环境变量的逻辑。
- 有效写法：
COMPOSER_MEMORY_LIMIT=-1 composer install（注意等号无空格） - Windows CMD 下需用
set COMPOSER_MEMORY_LIMIT=-1 && composer install，PowerShell 则用$env:COMPOSER_MEMORY_LIMIT="-1"; composer install - 该变量对
composer update生效明显，但对install效果有限——因为 install 主要消耗在解包和 symlink，这部分由 PHP 进程承担，不受 Composer 变量控制
减小内存压力的实操替代方案
硬提内存只是治标。有些项目依赖树极深、包体积极大（如含 node_modules 的私有包），光调内存也救不了。这时得从流程上“瘦身”。
- 加
--no-dev：跳过require-dev包，CI 构建或线上部署必加 - 用
--prefer-dist（默认开启）：强制走 zip 包而非 git clone，避免 git 操作吃内存 - 删掉
vendor和composer.lock后重试：锁文件损坏或版本冲突会引发异常内存占用 - 升级 Composer：2.x 比 1.x 内存管理更优，运行
composer self-update确保是最新稳定版
PHP 配置与 Composer 版本的隐性兼容问题
某些旧版 Composer（如 1.10.x）在 PHP 8.1+ 上会因类型检查变严而反复重试解析，间接推高内存峰值；反过来，PHP 7.4 下强行用 Composer 2.5+ 的新特性（如插件 API v2）也可能触发未捕获异常，导致内存泄漏式增长。
- 查 Composer 版本：
composer --version，推荐保持 >= 2.2.0 - 查 PHP 版本及 ini 路径：
php -v && php --ini - 若共存多个 PHP 版本（如 via asdf、brew、XAMPP），务必确保
composer命令调用的是你修改过的那个 PHP
composer diagnose，它能暴露很多隐藏线索：PHP 版本不匹配、openssl 扩展缺失、cache 路径不可写……这些都可能让 Composer 进入低效重试循环，把 512M 撑到爆。 
