php -d memory_limit=-1 并非万能解法，因其在CI/CD或Docker中可能触发OOM Killer导致进程被静默杀死，且部分环境明确拒绝-1值；应优先使用COMPOSER_MEMORY_LIMIT=2G等具体上限值，并配合--no-dev、clear-cache、关闭xdebug等减负措施。
php -d memory_limit=-1 为什么不是万能解法
本地开发时加 php -d memory_limit=-1 确实能快速绕过报错，但 CI/CD 或 Docker 容器里它可能触发 OOM Killer 杀进程，错误变成无声的 Killed，连堆栈都不输出。这不是 Composer 崩溃，是系统强制回收内存。
- GitHub Actions 默认容器总内存约 7GB，PHP 进程设
-1后会一路吃满，最终被 kill - Docker Desktop macOS 版默认只分配 2GB 内存，即使 PHP 设了
3G也会失败——得先调高 Docker 的内存配额 - 某些共享主机或 Jenkins slave 明确拒绝
-1值，返回Invalid memory limit
COMPOSER_MEMORY_LIMIT=2G 比 php.ini 更靠谱的场景
环境变量方式不依赖 PHP 配置路径，对 CLI 模式天然友好，尤其适合自动化脚本和多环境部署。
- Git Bash 或 WSL 下用
export COMPOSER_MEMORY_LIMIT=2G有时会被 shell 配置覆盖，建议直接写进命令行：COMPOSER_MEMORY_LIMIT=2G composer install - Windows CMD 不支持空格，必须写成
set COMPOSER_MEMORY_LIMIT=2G && composer install - 该变量对
composer dump-autoload也生效，但这个命令本身内存占用低，一般不需要调
为什么改 php.ini 往往白忙活
你改的很可能不是 Composer 实际加载的那个配置文件。CLI 和 Web SAPI 使用完全独立的 php.ini，而 Docker、MAMP、XAMPP 还自带隔离的 CLI 配置。
- 运行
php --ini查看 CLI 加载的真实路径，别只信phpinfo()里 Web 模块显示的地址 - 在容器里执行
docker exec -it app php --ini，而不是宿主机上查 - 改完后用
php -r "echo ini_get('memory_limit');"验证，输出应为2147483648或2G，不是-1或128M
真正省内存的操作比调参数更有效
很多“内存不足”本质是 Composer 在干多余的事，强行加内存只是掩盖问题。
-
composer install比composer update内存开销小 3–5 倍——只要composer.lock是最新的，就别碰update - 加
--no-dev能跳过所有require-dev包的解析，生产部署必须加上 - 旧缓存损坏会导致异常内存分配，先跑
composer clear-cache再重试 - xdebug 开着会让 Composer 内存翻倍，CI 中务必关掉：
php -d zend_extension= -d xdebug.mode=off composer install
