谢谢@Matteo，
问题是否可能是服务器上剩余的可用 RAM 量？
我已经验证了内存限制，但不认为这是问题。
php-cli -i | grep memory
但是，我已经解决了我的问题。实际上有三种方法可以解决它：
1.在没有 Composer 的情况下安装包
这不是推荐的解决方案，但知道如何去做通常非常有用，尤其是在非常过时的项目中，并且您担心命令composer update会产生问题
本指南假设您在本地服务器上没有内存限制问题，因此所有命令都可以在 composer 中正常工作。
首先，您必须在本地机器上安装捆绑包，例如：
composer require jms/serializer-bundle
安装包后，你只需要将包添加到你的 AppKernel.php 文件中：
// in AppKernel::registerBundles()
$bundles = array(
// ...
new JMS\SerializerBundle\JMSSerializerBundle(),
// ...
);
第二，从你的bundle目录打开composer.json，例如
// \vendor\jms\serializer-bundle\JMS\SerializerBundle\composer.json
"require": {
"php": ">=5.4.0",
"jms/serializer": "^1.0.0",
"phpoption/phpoption": "^1.1.0",
"symfony/framework-bundle": "~2.3|~3.0"
},
对于“require section”中的每个bundle，打开对应的composer.json来识别所有需要的bundle。
目的是复制所有这些捆绑包的目录并将它们上传到“供应商”目录中的远程服务器（注意保持相同的大目录层次结构）
例如：
如果你从 jms/serializer 包中打开 composer.json，你可以看到：
// vendor/jms/serializer/composer.json
"require": {
"php": ">=5.4.0",
"jms/metadata": "~1.1",
"jms/parser-lib": "1.*",
"phpcollection/phpcollection": "~0.1",
"doctrine/annotations": "1.*",
"doctrine/instantiator": "~1.0.3"
},
现在，您应该从 jms/metadata、jms/parser-lib 和 phpcollection/phpcollection 打开 composer.json 以识别您必须上传到远程服务器的其他包。
目标是不丢失任何依赖项。
最后，从远程服务器打开/vendor/composer/autoload_namespaces.php 并添加您的捆绑包依赖项的所有命名空间。您应该将此文件与您本地的“autoload_namespaces.php”进行比较。
2。添加交换空间
您有三个选择：创建新的交换分区、创建新的交换文件或在现有 LVM2 逻辑卷上扩展交换。建议您扩展现有的逻辑卷。
3.在本地更新作曲家以仅在远程安装
这是进行良好编程实践的推荐选项。当composer update 在第三个项目上完成时，我们不知道会发生什么错误，但是当您有足够的时间进行开发并且从现在开始该项目将归您所有时，您应该对项目进行全面升级。首先使用composer update 在您的本地服务器上更新并解决出现的所有冲突。最后，随着 composer.json 和 composer.lock 在服务器上更新，从现在到永远只需要运行 composer install 来安装和更新新包的所有依赖项。
Matteo 的解释是对的，composer update 命令占用的内存比composer install 多很多。
但你知道，你通常应该在你的机器上运行更新，然后提交/部署 composer.lock 文件，并且只在你的服务器上运行 install 以将依赖项与锁定文件同步，以确保你只得到你正确测试的东西。这样，您也可以毫无问题地运行内存不足的服务器。