如何正确使用Composer安装Laravel扩展包

Composer更新这个命令在我们目前的逻辑中，可能会对项目造成很大的危害。

因为composer更新的逻辑是根据composer.json指定的扩展包版本规则将所有扩展包更新到最新版本.注意是所有扩展包。比如你在项目开始的时候用了monolog，当时的配置信息是

“独白/独白”:“1。*",

Monolog 1.1版本安装，现在一个多月过去了，Monolog是1.2，运行命令后直接更新到。

1.2，这个时候项目不是针对1.2的。

经过测试后，项目突然变得非常不稳定，情况有时比这更糟糕，尤其是在一个巨大的项目中，你没有为项目编写一个完整的覆盖测试，你不知道什么地方坏了。

我应该使用哪个命令？安装、更新还是需要？

接下来，我们将逐一解释。

简单的解释

composer install——如果有composer.lock文件，直接安装；否则，从composer.json安装最新的扩展包和依赖项；

composer update-从composer.json安装最新的扩展包和依赖项；

composer update vendor/package-from composer . JSON或对应包的配置，并更新到最新；

composer require new/package-添加并安装new/package，并且可以指定版本，比如composer require new/package ~2.5。

程序

接下来，我们将介绍几个日常制作过程，以帮助加深我们的理解。

过程1:新项目过程

创建composer.json并添加依赖的扩展包；

运行composer install，安装扩展包并生成composer。锁；

将composer.lock提交给代码版本控制器，比如git

流程2:项目合作者安装现有项目。

克隆项目后，直接在根目录下运行composer install，从composer.lock安装指定版本的扩展包及其依赖项；

此流程适用于生产环境代码的部署。

过程3:为项目添加一个新的扩展包。

使用composer添加扩展包需要供应商/包；

将更新后的composer.json和composer.lock提交给代码版本控制器，比如git

关于composer.lock文件

composer.lock文件存储了依赖于每个代码的版本记录(见下图)，提交给版本控制者，与composer install一起使用，保证团队中所有协作者的开发环境和在线生产环境中运行的代码版本的一致性。

关于扩展包的安装方法

然后，要添加扩展包，可以使用install、update、require这三个命令来安装扩展包。选择哪个才是正确的？

答案是:使用composer require命令。

另外，手动修改composer.json添加扩展包后，composer update new/package也可以正确安装，但不推荐这种方法，因为一旦忘记敲定后期扩展包的名称，就会进入万劫不复的状态，不要给自己留坑。

以上概念，无论是新手还是老手，都很困惑。记住这个概念:

原项目新增的扩展都是以composer require new/package的方式安装的。

完成了。