应临时提高PHP内存限制，使用php -d memory_limit=2G composer install等命令，因Composer运行依赖PHP进程内存，而非其自身变量COMPOSER_MEMORY_LIMIT。
Composer 执行时提示 Allowed memory size exhausted 怎么办
直接原因是 PHP 当前可用内存低于 Composer 运行所需，尤其在 composer install 或 composer update 时加载大量依赖、解析锁文件或执行脚本阶段极易触发。这不是 Composer 本身的问题，而是 PHP 进程的 memory_limit 设置过低 —— 默认通常只有 128M 或 256M，而现代项目（尤其含 Laravel、Symfony 或大量 dev-dependencies）常需 1G+。
临时提高内存：用 -d memory_limit 最快生效
这是最常用、最安全的临时方案，不改动系统配置，只对当前命令生效。注意必须放在 composer 命令**之前**，且参数值要带单位（M 或 G）：
php -d memory_limit=2G /usr/bin/composer install
常见组合写法（适配不同环境）：
-
php -d memory_limit=-1 composer install：设为无限制（仅限可信环境，生产慎用） -
php -d memory_limit=1536M composer update：明确指定 1.5G，比 -1 更可控 - Windows 用户若用
composer.bat，需改用php -d ... composer.phar install，因为 .bat 会绕过 php.ini
为什么不能只改 php.ini 的 memory_limit
因为 Composer 实际运行的是 CLI 模式的 PHP，它读取的是 php.ini 的 CLI 配置文件，而非 Apache/Nginx 下的 CGI/FPM 版本。二者路径常不同：
- 查 CLI 配置位置：
php -i | grep "Loaded Configuration File" - 典型路径如：
/etc/php/8.1/cli/php.ini（Ubuntu）或/usr/local/etc/php/8.2/php.ini（Mac Homebrew） - 改错文件（比如只改了
fpm/php.ini）完全无效
即使改对了，也要注意：某些托管环境（如共享主机、CI 环境）不允许修改全局 php.ini，此时必须用 -d 方式。
COMPOSER_MEMORY_LIMIT 环境变量是否可靠
Composer 自 1.7+ 支持该变量，但行为有陷阱：
- 它只影响 Composer **自身逻辑**的内存分配，不改变底层 PHP 进程的
memory_limit - 如果 PHP 层已因内存不足崩溃（如
Allowed memory size exhausted），这个变量根本没机会生效 - 正确用法是配合
-d使用，或仅用于微调（如COMPOSER_MEMORY_LIMIT=512M php -d memory_limit=1G composer install）
单独设置 COMPOSER_MEMORY_LIMIT=-1 无法解决底层 PHP 内存耗尽问题，这点很多人踩坑。
真正关键的是分清层级：PHP 进程内存上限（-d memory_limit）是硬门槛，Composer 变量只是软策略。项目越大，越要优先确保前者足够宽裕；否则所有优化都建立在崩溃之上。
