php -d memory_limit=-1 是让 PHP 解释器启动时彻底禁用内存限制，不统计、不报错、不中断；COMPOSER_MEMORY_LIMIT=-1 仅在 PHP 未中止时由 Composer 自行读取，故常失效。
直接加 php -d memory_limit=-1 就能跳过 PHP 层面的内存限制，这是最可靠、最通用的做法；COMPOSER_MEMORY_LIMIT=-1 只对 Composer 自身逻辑起作用，且在 PHP 已因 memory_limit 中断时根本不会执行到。
php -d memory_limit=-1 是什么原理？
它让 PHP 解释器在启动时就忽略 memory_limit 限制，Composer 进程从第一行代码开始就不受约束。这不是“绕过检查”，而是彻底关掉闸门——PHP 不再统计、不报错、不中断。
常见误操作：
- 写成
php -d memory_limit = -1（等号前后有空格）→ 参数解析失败，实际没生效 - 用
composer.phar install却漏了php前缀 → 直接调系统 PATH 下的二进制，没走 PHP 解释器 - 在 Docker 容器里改了宿主机的 php.ini → 容器内 CLI 用的是自己那套配置，
php --ini才是真相
COMPOSER_MEMORY_LIMIT=-1 为什么经常失效？
这个环境变量是 Composer 自己读的，但它只在 PHP 内存还没爆之前才来得及运行。一旦 PHP 因 memory_limit=128M 提前中止，Composer 根本没机会初始化，更别说读环境变量了。
适用场景有限：
- 对
composer update有效（依赖求解阶段会读） - 对
composer install效果弱（主要开销在解压、symlink、autoload dump，这些由 PHP 底层承担） - Windows PowerShell 需写成
$env:COMPOSER_MEMORY_LIMIT="-1"，CMD 则是set COMPOSER_MEMORY_LIMIT=-1
--no-autoloader --no-scripts --prefer-dist 组合为什么省内存？
这三者分别砍掉 install 流程里最吃内存的三个环节：
-
--no-autoloader：跳过vendor/autoload.php生成，避免扫描全部类文件并写大数组 -
--no-scripts：不执行post-install-cmd等脚本，比如前端构建、配置生成、缓存预热——这些常是内存黑洞 -
--prefer-dist：强制下 zip 包而非git clone，避免起子进程、解包、检出三重开销（尤其私有 GitLab 仓库）
典型命令：php -d memory_limit=-1 composer install --no-autoloader --no-scripts --prefer-dist --no-dev
opcache.enable_cli=1 要不要开？
要开，但必须配对设置：opcache.memory_consumption=64（单位 MB），别设成 256 或 512——CLI 场景下 opcache 占太多内存，反而挤占 Composer 可用空间。
验证是否生效：php -d opcache.enable_cli=1 -i | grep "opcache.enable_cli" 输出应为 On；若仍报内存不足，临时禁用：php -d opcache.enable=0 -d memory_limit=-1 composer install。
容易被忽略的一点：PHP 8.1+ 若启用了 opcache.preload，Composer 在 autoload dump 阶段可能意外触发预加载逻辑，导致内存峰值翻倍——这时不是加内存能解决的，得先关 preload。
