composer install将在composer.lock文件中声明时安装,但composer update将更新所有依赖项并根据所需内容创建新 composer.lock文件composer.json.
这么多说只是composer update在开发中运行.但我的问题是做composer update了更换旧composer.lock文件,如果你的应用程序要打破它会破坏,因为可能与新更新的依赖项有冲突.
我遇到了一个必须要做的情况composer update,问题与pcntl扩展有关.唯一的解决方案是pcntl 安装PHP pcntl模块
我不明白为什么人们害怕这样做composer update.
我对此的想法是,
composer-update需要,我宁愿这样做:
composer update,composer install不要运行，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”目录中，预热某种类型的缓存，诸如此类），这将是个好时机去做吧。
应当测试上述步骤的结果（通常在过渡环境中），然后将其推送到整个生产环境（您的客户代码，供应商文件夹，针对产品量身定制的配置等）；使用您喜欢的任何部署方法。