php -d memory_limit=2G可解决Composer内存不足，但必须加在php命令后、composer命令前；若漏写php前缀、PHP配置路径错误、PowerShell未加引号或CI禁用-d参数，则失效。
直接加 php -d memory_limit=2G 就能解决，但必须加对位置、加对值，否则还是报 Allowed memory size exhausted。
为什么 php -d memory_limit=-1 有时没生效
它只作用于紧随其后的 PHP 进程，但容易被环境绕过：
- 你运行的是
./composer.phar却漏了php前缀，实际走的是系统默认 PHP（可能仍是 128M） -
which php和php --ini输出的 “Loaded Configuration File” 路径不一致——你改的可能是 FPM 的php.ini，CLI 根本不读 - Windows PowerShell 下没加引号：
php -d "memory_limit=-1"缺失双引号会导致参数截断 - GitLab Runner 等 CI 环境明确禁用
-d参数，此时必须靠COMPOSER_MEMORY_LIMIT=-1兜底
composer require 该用什么参数组合
这个命令本质是先做 update 再做 install，内存压力比纯 install 高得多。推荐组合如下：
-
php -d memory_limit=2G composer require vendor/package—— 最基础有效 - 加
--no-dev --no-plugins --no-scripts -o可再降 40%~60% 内存峰值 - 若项目不用 xdebug，务必临时关掉：
php -d zend_extension= -d xdebug.mode=off -d memory_limit=2G composer require ... - 避免在
require同时更新 lock 文件：先确认composer.json干净，再执行
composer.lock 文件太大也会导致内存溢出
不是下载慢，是解析 JSON + 重建依赖图时爆内存。一旦 ls -lh composer.lock 显示 >3MB，就要警惕；>5MB 几乎必崩。
- 别删
vendor/和composer.lock后直接require——这等于触发全量 SAT 求解，内存峰值更高 - 优先用轻量安装跳过非核心逻辑：
composer install --no-dev --no-plugins --no-scripts -o - CI/CD 中要校验 lock 是否合法：
composer validate --no-check-publish - 若必须精简，可用
jq删掉packages-dev、content-hash等非运行必需字段
真正容易被忽略的是：内存限制只是表象，composer.lock 膨胀、xdebug 开着、CI 缓存污染、容器本身内存不足——这些都可能让 -d memory_limit=2G 显得毫无作用。
