根本原因是composer默认受php内存限制约束，现代项目易超限；应使用php -d memory_limit=-1 composer.phar install等命令临时提权，而非改php.ini，因composer cli可能绕过全局配置。
Composer install/update 卡住并报 Allowed memory size exhausted
根本原因是 Composer 默认用 PHP 的内存限制（通常是 128M 或 256M）跑完整个依赖解析和安装流程，而现代项目（尤其含大量 dev 依赖或插件的 Laravel/Symfony 项目）很容易突破这个阈值。
直接调高内存不是万能解法，但确实是最快生效的手段。关键在于：必须让 composer 命令本身启动时就获得足够内存，而不是依赖 php.ini 全局设置——因为 Composer CLI 可能绕过你改的 php.ini。
- 临时生效（推荐优先试）：
php -d memory_limit=-1 /usr/bin/composer install
（memory_limit=-1表示无限制；路径/usr/bin/composer换成你本地的composer实际位置，可用which composer查） - 如果用的是
composer.phar直接下载版，写成：php -d memory_limit=-1 composer.phar install
- Windows 用户注意：不要用
composer install直接调用，它背后可能走的是另一个 PHP 配置；坚持用php -d ... composer.phar ...形式
为什么设成 -1 而不设 2G？
设 2G 看似稳妥，但部分系统（尤其是某些 Docker 容器或共享主机）会因底层 cgroup 限制或 PHP 编译选项，导致设具体数值反而触发更早的 OOM kill；而 -1 是让 PHP 尽可能用尽可用内存，Composer 自身有逻辑控制资源使用节奏，实际极少真吃光所有内存。
这不是偷懒，是 Composer 官方在 issue 中明确建议的模式（见 #7092 等）。只要机器本身有 2G+ 可用内存，-1 比硬编码 2048M 更可靠。
- 别在
php.ini里全局改memory_limit—— 可能影响其他 CLI 工具甚至 Web 请求 - 别用
ini_set('memory_limit', ...)—— Composer 启动阶段就已读取配置，运行时修改无效 - Mac M1/M2 用户若用 Rosetta 运行 PHP，偶尔会遇到内存映射异常，此时换原生 ARM PHP（如 via Homebrew）比加内存更治本
还有哪些操作会触发内存爆掉？
不只是 composer install，以下命令同样高危，需统一用 php -d memory_limit=-1 前缀：
-
composer update（依赖图重算最耗内存） -
composer require xxx（尤其加新包时要重新解析全量 lock） -
composer dump-autoload -o（优化自动加载本身不耗内存，但若前置触发了 autoload 重建逻辑，可能连带拉起整个依赖分析） - CI 环境跑
composer install --no-interaction --prefer-dist也得加前缀，否则流水线静默失败
实在不想调内存？试试这些轻量替代方案
适合 CI、低配服务器或想长期规避问题的场景。它们不解决“大项目必耗内存”的本质，但能绕开最重的环节：
- 用
--no-dev：生产环境部署时加这个参数，跳过所有require-dev包，内存占用常降 40%~70% - 删掉
vendor/和composer.lock再装？别。清 lock 文件会让 Composer 重新 resolve 全量依赖，更费内存。保留 lock，只删 vendor - 升级 Composer 到 2.5+：新版用了更紧凑的依赖解析器，同项目下内存峰值平均降低 25%，且默认启用 lazy provider 加载
- Docker 构建时，在
php:xxx-cli镜像里加一句ENV COMPOSER_MEMORY_LIMIT=-1，一劳永逸
真正难搞的是 monorepo 项目里跨 package 的循环依赖检测，那部分逻辑几乎无法绕过，该加内存还得加——别信“我用 --dry-run 就能省内存”，它照样做完整解析。
