结论：COMPOSER_MEMORY_LIMIT不能突破PHP memory_limit瓶颈，仅对Composer依赖解析起软限制；真正生效的是php -d memory_limit=2G（单位大写、顺序正确、PowerShell需加引号），它直接作用于PHP进程底层限制。
直接说结论：调整 COMPOSER_MEMORY_LIMIT 环境变量**不能突破 PHP 进程的 memory_limit 瓶颈**，它只在 Composer 自身依赖解析阶段起软限制作用；真正卡死你的，是 PHP 底层抛出的 Fatal error: Allowed memory size of XXX bytes exhausted。
为什么 COMPOSER_MEMORY_LIMIT=-1 仍然报错
这个环境变量被误传为“Composer 内存开关”，但它实际只影响 Composer 内部几个可中断的循环逻辑（比如递归求解依赖时主动退出），而以下操作完全不受它控制：
- 下载并解压 ZIP 包（
ext-zip解压过程由 PHP 原生函数执行） - 生成
vendor/autoload.php映射（尤其是扫描大量文件或含files类型 autoload 时） - 执行
post-install-cmd脚本（这些脚本运行在同一个 PHP 进程里，受原始memory_limit约束）
也就是说：一旦 PHP 进程本身因内存超限被内核 kill 或抛出 Fatal，COMPOSER_MEMORY_LIMIT 根本没机会生效。
php -d memory_limit 才是真正起效的命令行方式
这是唯一能绕过默认配置、且立即作用于当前进程的方式。注意三个关键细节：
立即学习“PHP免费学习笔记（深入）”；
- 顺序必须是
php -d memory_limit=2G composer install，不能写成composer install -d memory_limit=2G - 单位必须大写：
2G✅，2g❌（小写会被 PHP 忽略，退回到默认值） - Windows PowerShell 用户必须加引号：
php -d "memory_limit=-1"，否则-1可能被 shell 截断
如果你用的是宝塔面板内置 Composer，路径要写全：php -d memory_limit=2G /www/server/php/82/bin/php /www/server/php/composer.phar install。
哪些场景下 COMPOSER_MEMORY_LIMIT 还有点用
它不是全无价值，但在非常有限的条件下才起作用：
- 你正在跑一个极深的、存在循环依赖风险的
composer update，设COMPOSER_MEMORY_LIMIT=1536M可让 Composer 在内存爬升到 1.5G 时主动中止，避免无休止等待后崩溃 - 某些第三方插件（如
hirak/prestissimo旧版）内部会读取该变量做缓冲区预分配，但这类行为已基本被 Composer 2.5+ 废弃 - CI 环境中作为第二道防线：先设
php -d memory_limit=2G，再加COMPOSER_MEMORY_LIMIT=1800M防插件失控
它优先级低于 php -d，高于 php.ini，但永远无法覆盖 PHP SAPI 层的硬性限制。
别碰 memory_limit = -1 的全局 php.ini
CLI 模式下设 memory_limit = -1 看似一劳永逸，但隐患明显：
- 所有 CLI 脚本（包括
php artisan、drush、甚至你写的备份脚本）都失去内存兜底，一次循环引用就可能把服务器拖慢 - 部分 CI 平台（如 GitHub Actions）会主动拦截
-1值，强制回落到 128M，导致行为不一致 - 掩盖真实问题：比如
composer.json中写了"autoload": {"files": ["huge-legacy-lib.php"]}，这才是该优化的点，不是提内存
更稳妥的长期做法是：确认 CLI 实际加载的 php.ini（用 php --ini 查），改成 memory_limit = 2G，并配合 --no-dev -o 使用。
真正容易被忽略的点是：你以为在调 Composer 的内存，其实你在调 PHP CLI 进程的内存——而 Composer 只是那个最常触发上限的用户而已。
