最快速有效方式是php -d memory_limit=-1 composer.phar install，但需确认PHP CLI路径正确、避免wrapper干扰、CI中禁用-d时改用COMPOSER_MEMORY_LIMIT配合--no-dev等参数，并注意Docker内存限制与autoload配置风险。
直接加 php -d memory_limit=-1 就能过，但得确认它真作用在 CLI PHP 上——否则再调也是白费。
为什么 php -d memory_limit=-1 composer install 有时没用
根本原因不是命令写错，而是 PHP CLI 没加载到你认为的那个配置。比如你改了 /etc/php/8.2/apache2/php.ini，但 Composer 跑的是 /etc/php/8.2/cli/php.ini，完全不搭界。
- 先执行
php --ini，盯住Loaded Configuration File那一行，才是 Composer 实际读的 ini 文件 - 再跑
php -r "echo ini_get('memory_limit');"，看输出是不是-1或2G，不是就说明参数没生效 - Windows Git Bash 下
php -d可能被 shell 错误解析，换 PowerShell 或 CMD 更稳 - 某些容器（如 GitHub Actions 的
ubuntu-latest）默认只给 PHP 进程约 1.5G，-1会被系统 OOM killer 杀掉，此时必须设具体值，比如2G
COMPOSER_MEMORY_LIMIT 和 php -d 到底谁管用
COMPOSER_MEMORY_LIMIT 是 Composer 自己读的开关，但它只控制 Composer 内部对象分配逻辑；一旦底层 PHP 因 memory_limit=128M 直接崩溃，这个变量根本没机会执行。
- 优先级：PHP 的
memory_limit>COMPOSER_MEMORY_LIMIT - 有效写法（无空格）：
COMPOSER_MEMORY_LIMIT=-1 composer install - PowerShell 要写成：
$env:COMPOSER_MEMORY_LIMIT="-1"; composer install - 它对
composer update效果明显，但对install帮不大——因为解压和 symlink 是 PHP 干的，不是 Composer 控的
不靠硬提内存，怎么让 composer install 真的变轻
很多项目卡在 install 阶段，其实不是缺内存，是流程太重。锁文件过大、dev 包全装、autoload 未优化，三者叠加就爆。
- 加
--no-dev：跳过所有require-dev，线上部署必加 - 加
--prefer-dist：强制走 zip 包，避免 git clone 吃内存（Composer 2.x 默认开启，但旧 lock 文件可能失效） - 加
-o（即--optimize-autoloader）：生成扁平化 autoload map，减少运行时解析开销 - 删掉
vendor/和composer.lock重来：锁文件损坏或含大量dev-master提交哈希时，解析耗内存翻倍 - 升级 Composer：
composer self-update到 2.5+，SAT 求解器和 JSON 解析层有显著内存优化
Docker / CI 环境里最容易漏掉的一环
本地好好的，CI 报错，八成是因为容器里 PHP 没继承 host 的配置，或者用了精简镜像（如 php:8.2-cli-alpine），连 memory_limit 都没设。
- GitHub Actions 中别只写
run: composer install，要写成run: php -d memory_limit=2G composer install --no-interaction - Dockerfile 中，如果 base image 不带完整 PHP 配置，得手动加一行：
RUN echo "memory_limit = 2G" > /usr/local/etc/php/conf.d/memory.ini - GitLab CI 的
before_script里设export COMPOSER_MEMORY_LIMIT=2G不够，必须同步确保 PHP CLI 的memory_limit也够——否则变量还没读完进程就死了
真正卡住的点往往不在“要不要加内存”，而在于没分清：是 Composer 在算依赖（update），还是 PHP 在解包（install），或是 autoload 在建映射（dump-autoload）。每个阶段瓶颈不同，混着调只会掩盖真实问题。
