首先要搞清楚的一件事情是，所有的依赖都定义在composer.json中，手册中给出了一些基本用法和例子。你可能已经注意到，在指定版本号的时候，我们并不一定要指明一个精确的版本。那么就有可能发生这么一个情况，对于同一份composer.json，我们在不同时刻拉取到的依赖文件可能不同（因为composer会在满足条件的情况下去拉取最新的那份依赖），从而导致一些异常情况。
composer update和composer install正是为了解决这个问题而出现的。
当你执行composer update的时候，composer会去读取composer.json中指定的依赖，去分析他们，并且去拉取符合条件最新版本的依赖。然后他会把所拉取到的依赖放入vendor目录下，并且把所有拉取的依赖的精确版本号写入composer.lock文件中。
composer install所执行的事情非常类似，只在第一步的时候有差别。当你本地如果已经存在一份composer.lock时，它将会去读取你的composer.lock而非composer.json，并且以此为标准去下载依赖。当你本地没有composer.lock的时候，它所做的事情和composer update其实并没有区别。
这意味着，只要你本地有一份composer.lock，你就可以保证无论过去了多久，你都能拉到相同的依赖。而如果你把它纳入你的项目的版本控制中，那么你就可以确保你项目中的每一个人、每一台电脑，不管什么系统，都能拉取到一模一样的依赖，以减少潜在的依赖对部署的影响。当然，请记得，你应该使用的命令是composer install。
其实composer install和composer update的区别，我们执行composer命令后就可以很明显看到
image.png
那么什么时候需要使用composer update呢？比如某扩展发布的新版本有我们需要的新功能时，这时我们需要更新该扩展，我们update时指定具体更新的扩展名，如composer update monolog/monolog，而不要直接composer update。因为直接composer update后，所有的扩展都会更新，风险很大。
总结:
-
composer update是根据composer.json来更新的，并把扩展的版本号写入到composer.lock中。
-
composer install是根据composer.lock来更新的，应该把composer.lock文件纳入到项目的版本控制中，然后使用composer install来下载，这样可以保证每个人下载到的扩展是一样的。开发人员尽量使用composer install 而不要使用composer update
-
需要更新某扩展时，使用update指定具体需要更新的扩展，不要直接使用composer update
-
在composer install或者composer update时发现很慢时，第一步应该更换composer源，安装官网修改成国内源
-
composer install或者composer update时候经常会卡住不动，此时我们可以加上-vvv参数看到具体执行过程，可以看到卡到哪步了
composer install -vvv
网友评论