最稳解法是php -d memory_limit=2G composer install，因该参数必须作用于Composer进程本身；若which composer返回shell wrapper（如/usr/bin/composer），需改用绝对路径调用phar文件，且COMPOSER_MEMORY_LIMIT仅控制Composer内部逻辑，不绕过PHP底层限制。
直接加 php -d memory_limit=2G 是最稳、最通用的解法，不是调高 PHP 配置就能解决，而是必须确保这个参数真正作用于 Composer 进程本身。
为什么 php -d memory_limit=-1 经常失效
根本不是参数写错了，而是你执行的 composer 命令压根没走 PHP 解释器。Ubuntu 用 apt install composer 安装时，which composer 返回的是 /usr/bin/composer —— 这是个 shell wrapper，-d 参数被完全忽略。
- 验证方式：运行
ls -l $(which composer)，如果看到它指向脚本或二进制文件，就确认是 wrapper - 正确写法：用绝对路径调 PHAR 文件，例如
php -d memory_limit=2G /opt/composer.phar install - Windows PowerShell 必须加引号：
php -d "memory_limit=2G" composer install，否则-1或2G被当成 PowerShell 参数解析 - CI 环境（如 GitHub Actions）可能显式禁用
-1，此时2G是更稳妥的选择
COMPOSER_MEMORY_LIMIT 环境变量的真实作用范围
它只控制 Composer 自身逻辑（比如依赖求解缓存大小），**完全不绕过 PHP 的 memory_limit 底层限制**。PHP 进程在第 129MB 就被内核 kill，Composer 根本没机会读到这个变量。
- 生效场景极少：仅当 Composer 主动报
Not enough memory, need XXX more这类提示时才起作用 - Linux/macOS 正确写法：
COMPOSER_MEMORY_LIMIT=2G composer install（等号前后不能有空格） - 对
composer install几乎无效——解包和软链由 PHP 直接操作；对composer update有轻微缓解，因影响依赖缓存策略 - 加
-v参数可验证是否生效：开头几行会打印Memory limit: 2G
哪些参数组合能真正减负，而不是硬扛内存
盲目提内存只是掩盖问题，尤其在 CI/CD 或 Docker 环境里。真正有效的参数组合聚焦在跳过非必要环节：
- 加
--no-dev：跳过require-dev包，部署环境必加，可降 30%–60% 内存占用 - 加
--no-autoloader：跳过 autoload 生成，后续手动跑composer dump-autoload分步处理 - 加
--prefer-dist（默认开启）：强制走 zip 包而非 git clone，避免 git 操作吃内存 - 加
--ignore-platform-reqs：跳过平台检查，适合低配 CI 环境，配合缓存机制使用 - 禁用插件：
composer config -g disable-tls true无效，真正有用的是删掉废弃插件（如hirak/prestissimo）或关掉 xdebug：php -d zend_extension= -d xdebug.mode=off composer install
最易被忽略的一点：composer.lock 文件过大（比如超 5MB）会显著拖慢依赖解析，不是内存真不够，而是 JSON 加载和映射构建阶段卡住。别急着调参，先检查锁文件是否混入了 dev-master 提交哈希或冗余 package-versions 数据。
