Composer config命令动态调整内存上限以处理巨型依赖树解析

真正起作用的是 COMPOSER_MEMORY_LIMIT 环境变量

这是 Composer 自己主动读取的变量，用来控制依赖解析、缓存预估这些内部行为的软上限。但它绕不过 PHP 底层的 memory_limit——你可以把它想象成一道有弹性的栅栏，可栅栏外面还有一堵高墙。值必须合法并且前置执行：

• COMPOSER_MEMORY_LIMIT=-1 表示不限制（仅推荐调试时用）
• COMPOSER_MEMORY_LIMIT=2G 或 2048M 更稳妥（PHP 7.2+ 支持单位）
• COMPOSER_MEMORY_LIMIT=1073741824 是 1G 的字节数写法，兼容性最好
• Linux/macOS：直接 COMPOSER_MEMORY_LIMIT=2G composer install
• Windows CMD：set COMPOSER_MEMORY_LIMIT=2G && composer install
• PowerShell：$env:COMPOSER_MEMORY_LIMIT="2G"; composer install

php -d memory_limit 才是硬闸门

这是唯一能阻止“Allowed memory size exhausted”报错的方式。它在 PHP 进程启动前就强制设定了内存上限，绕过了所有配置干扰。用法也分场景：

• php -d memory_limit=-1 composer install（Linux/macOS/Windows CMD）
• Windows PowerShell 要加引号：php "-d" "memory_limit=-1" composer install
• 若用 composer.phar，必须写成 php -d memory_limit=-1 composer.phar install，顺序不能错
• 千万别写成 php -d memory_limit=-1 $(which composer)——shell wrapper 会吞掉你的 -d 参数

为什么有时调高内存还是 OOM

折腾了半天内存上限，结果进程仍然被 kill 掉，问题往往不是出在数值上，而是另有隐情：

• xdebug 还开着：本地开发习惯开它，但内存占用能翻倍以上。CI 里务必关掉：php -d zend_extension= -d xdebug.mode=off composer install
• 循环依赖或 autoload 规则太宽：比如 "psr-4": {"": "src/"} 会扫描整个 vendor 目录，白白吃掉大量内存
• composer.lock 损坏或 vendor 残留：先清掉再试：rm -rf vendor composer.lock && composer clear-cache
• Docker 容器里没同步 cgroup 限制：即使你设了 COMPOSER_MEMORY_LIMIT=-1，宿主机仍然可能按 cgroup 规则 kill 掉进程

最容易被忽视的一点：Composer v2+ 启动后会主动检查并覆盖 PHP 的 memory_limit。如果你强行用 php -d memory_limit=-1 composer.phar，反而会触发它的保护逻辑，直接报错 Composer requires the memory limit to be set to a value greater than 0。这时候必须改用 COMPOSER_MEMORY_LIMIT 环境变量前置执行——先设环境变量，再跑 Composer，顺序不能反。