composer install将在composer.lock文件中明确安装，但composer update将更新所有依赖项并创建基于新 composer.lock的文件在composer.json。
许多人说只在开发中运行composer update。但我的问题是，composer update确实替换了旧的composer.lock文件，如果您的应用程序要破解它将会中断，因为可能与新更新的依赖项存在冲突。
我遇到的情况是我必须composer update，问题与pcntl扩展有关。唯一的解决方案是composer update PHP pcntl module installation
我不明白为什么人们害怕做composer update。
答案 0 :(得分：7)
我对此的看法是，
composer-update，我宁愿这样做：
composer update，composer install 答案 1 :(得分：7)
请勿在生产环境中运行composer update或composer install。在其他地方执行它，然后将结果上传到生产环境。但是，如果您要运行以下两种方法之一，请始终运行install并创建全新的安装；永远不要update。 install更具可预测性和可靠性，而update则受项目任何依赖项的支配。
Composer递归工作。因此，即使您的composer.json中的版本约束非常严格，通过运行composer update，您不仅可以更新依赖关系，还可以更新依赖关系的依赖关系。
虽然大多数时候不会出现破损，但有时会破损。一线依赖可能会导致行为改变，从而可能以您未测试的方式影响您的代码。
此外，它基本上是在使用错误的工具来完成工作。 Composer是依赖性管理工具，而不是部署工具。要将代码部署到生产环境中，您应该使用某种代码部署工具（即使该“工具”与FTP上传和几个脚本一样简单）。
适当的流程是：
require和update调用，您可以在其中无风险地测试项目。这样会生成composer.lock，这是整个项目的已知状态，并且安装了离散的版本。使用install --no-dev创建一个新可安装版本。在这一步上，您还应该转储优化的自动加载器，运行安装后脚本等。我通常将其分为多个步骤：
composer install --prefer-dist --no-scripts --no-progress --no-suggest --no-interaction --no-dev：
^^这是对所有内容的完整，静默安装，不包括开发依赖项。
composer dump-autoload --optimize --no-dev
^^转储适合生产的优化自动装带器脚本。
composer run-script --no-dev post-install-cmd
^^这主要用于Symfony，但是如果您要运行任何安装后脚本（例如，将资产复制到“ public”目录中，预热某种类型的缓存，诸如此类），这将是一个好时机。
应该测试上述步骤的结果（通常在过渡环境中），然后将其推送到整个生产环境（您的客户代码，供应商文件夹，为产品量身定制的配置等）；使用您喜欢的任何部署方法。
答案 2 :(得分：0)
我的想法：
你绝不应该使用没有参数的作曲家更新 。
composer update读取composer.json上列出的每个包，并将其更新为与指定版本约束兼容的最新可用版本。
在一个完美的世界中，所有的图书馆都会正确地遵循semver，并且不应该有任何副作用。但从技术上讲，这绝不是真的，你可以下载与前一个版本不兼容的版本，或者只是一个带有未修正错误的版本。
因此，一次更新所有包 可能会导致一些问题，除非您有时间检查网站上的所有内容以确保没有出错。
但是，当然，您有时必须更新特定的包，因此使用composer update xxx/xxx非常有用，假设您将检查所有包的实现。
当更新的软件包经过全面测试后，您可以将代码提交到暂存/生产，然后运行composer install以确保您在所有平台上拥有相同的软件包和依赖项版本。
长话短说，这是我使用的过程：
composer require xxx/xxx安装新软件包composer update xxx/xxx更新特定包composer install。其他想法
我偶然发现了一个可以在composer.json中提供包的确切版本的实现。开发人员解释说，通过这种方式，您可以使用composer update而不会受到损害。
我不同意这个选项，因为即使使用composer.json中的确切版本，依赖关系也不会修复，并且编辑器更新可能会导致其中的潜在错误。