composer install将在composer.lock文件中指定的任何时候安装，但composer update将更新所有依赖项，并根据composer.json中的要求创建一个新的composer.lock文件。
所以很多人说只运行composer update在开发中。但我的问题是，composer update是否替换了旧的composer.lock文件，如果你的应用程序要崩溃，它就会崩溃，因为可能会与新更新的依赖项发生冲突。
我遇到了一个必须执行composer update的情况，这个问题与pcntl扩展有关。唯一的解决方案是做composer updatePHP pcntl模块安装
我不明白为什么人们害怕在生产中运行composer update。
TLDR
不要在生产中运行composer update和composer install。在其他地方执行它，并将结果上传到生产服务器，但不要上传到托管应用程序的同一目录。一般来说，当正在被服务时，您不应该修改正在被服务的应用程序。创建一个不同的应用程序副本，当它准备好时，用最接近即时的命令(例如mv或ln -s)替换它。
但如果必须运行其中一个：请始终运行install并创建新的安装；而从不CCD_ 18。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的，但如果你有任何安装后脚本要运行(例如，将资产复制到"公共"目录，预热某种类型的缓存，诸如此类)，这将是一个很好的时机。
- 应测试上述步骤的结果(通常是在阶段环境中)，然后将其推送到整个生产环境(您的客户端代码、供应商文件夹、为产品定制的配置等)；使用您喜欢的任何部署方法
注意，如果您使用任何"；"慢"；push方法(FTP、copy、rsync等)，您不应该直接写入应用程序文件系统，而是创建应用程序的新副本，一旦文件传输准备就绪，请使用快速方法替换"；生产"；新版本。一种流行且有效的方法是使用符号链接作为"；生产"；root，因此您只需要在完成并准备好上述所有后更新符号链接，而不会影响正在运行的应用程序(否则，由于突然包含属于应用程序不同版本的文件，可能会暂时中断)。
我对此的想法是，
- 系统的当前工作状态非常重要，因为我认为已经针对它运行了一些测试
- 进行composer更新意味着，作为应用程序一部分的库将进行更新，这可能会导致系统崩溃。因为它们是依赖于依赖于库的库
- 最后，如果需要
composer-update，我宁愿这样做：- 在开发环境和CCD_ 32上进行校验
- 确保应用程序在开发环境中经过彻底测试
- 然后使用
composer install进行现场/生产安装
我在这里的想法：
您永远不应该在没有参数的情况下使用composer update。
composer update读取composer.json上列出的每个包，并将其更新为与指定版本约束兼容的最新可用版本。
在一个完美的世界里，所有的libraries都会正确地遵循semver，它不应该有任何副作用。但从技术上讲，这从来都不是真的，你可以下载一个与前一个不兼容的版本，或者只是一个有未更正错误的版本。
因此，一次更新所有软件包可能会导致一些问题，除非你有时间检查网站上的所有内容以确保没有任何问题。
当然，有时您必须更新特定的包，因此使用composer update xxx/xxx是有用的，假设您将检查包的所有实现。
当更新后的包经过完全测试后，您可以将代码提交到暂存/生产，然后运行composer install，以确保在所有平台上都有相同版本的包和依赖项。
长话短说，以下是我使用的流程：
composer require xxx/xxx安装新软件包composer update xxx/xxx更新特定程序包- 当package.lock文件已更新时，所有环境上的
composer install
其他想法
我偶然发现了一个实现，它将在composer.json中提供包的确切版本。开发人员解释说，通过这种方式，你可以在不损坏的情况下使用composer update。
我不同意这个选项，因为即使使用composer.json中的确切版本，依赖关系也不是固定的，composer更新可能会导致其中的潜在错误。