Composer内存不足报错源于PHP memory_limit限制，临时解决用php -d memory_limit=-1 composer install/update，CI中建议设2G~3G上限，避免-1在容器环境引发OOM。
composer install 或 update 报 Allowed memory size exhausted
这是最典型的内存不足报错，本质是 PHP 进程跑 Composer 时被 memory_limit 卡死了。不是 Composer 本身要多少内存，而是它加载大量包元数据、解析依赖树、执行脚本时会阶段性冲高内存——尤其在有几十个 require 的项目里，128M 默认值根本不够用。
临时解决就一条命令：在运行前把 PHP 内存限制拉高。不用改 php.ini，也不用重启服务。
- Linux/macOS：直接前缀
php -d memory_limit=-1（-1表示不限制），例如：php -d memory_limit=-1 composer install
- Windows CMD：同样有效，但注意双引号包裹参数更稳妥：
php -d "memory_limit=-1" composer install
- 如果用的是
composer命令别名（比如通过curl -sS https://getcomposer.org/installer安装的 phar），确保你调用的是php composer.phar而非系统 PATH 里的 shell wrapper，否则-d参数可能不生效
为什么不用改 php.ini？
改 php.ini 看似一劳永逸，但风险明显：全局调高 memory_limit 会影响所有 CLI 和 Web 请求，可能掩盖真实内存泄漏，甚至让一个失控的 Web 脚本吃光服务器内存。Composer 只在安装/更新阶段需要大内存，其他时候完全不需要。
另外，很多共享主机或 CI 环境（如 GitHub Actions）根本不允许改 php.ini，临时加参数是唯一可行路径。
-
php -d只影响当前进程，退出即失效，安全干净 - CI 脚本里推荐写死，比如 GitHub Actions 的
run步骤：php -d memory_limit=2G composer update --no-interaction
- 避免用
ini_set('memory_limit', ...)—— Composer 的 phar 是压缩包，入口逻辑早于用户代码，ini_set根本没机会执行
memory_limit=-1 真的安全吗？
理论上安全，但实际要看场景。-1 表示“不限制”，PHP 会一直申请直到系统内存耗尽或被 OOM Killer 干掉。对本地开发机问题不大；但在 CI 或资源受限的 Docker 容器里，必须设上限。
- 推荐值：本地开发可用
-1；CI 中建议显式设为2G或3G，既够用又防失控 - Docker 用户注意：
php -d memory_limit=3G不会突破容器--memory限制，但若设太高而容器内存不足，PHP 进程会被 kill，报错变成Killed（无堆栈），容易误判为 Composer bug - Mac 上用 Docker Desktop 默认只分 2GB 内存，即使 PHP 设了
3G也会失败——得先调高 Docker 的内存配额
还有哪些操作会触发内存爆掉？
不只是 composer install，以下操作同样敏感：
-
composer update：比 install 更耗内存，因为要重新计算整个依赖图，尤其是删了composer.lock后全量解析 -
composer require xxx：加新包时也要重算依赖，小项目不明显，Laravel + 高版本 Symfony 组件组合下很容易崩 - 使用
--with-all-dependencies或--update-with-dependencies：强制升级子依赖，树深度和节点数激增 - 项目根目录存在大量未忽略的临时文件（如
node_modules/、.git/子模块嵌套），Composer 的 autoloader 扫描或插件钩子可能意外遍历它们，间接推高内存
真正难察觉的是：某些 Composer 插件（比如自定义 installer 或 pre-update-cmd 脚本）会在内存峰值期执行额外 PHP 逻辑，让临界点更难预测。遇到反复爆内存又没动依赖时，先试 composer install --no-plugins 排查。
