1。composerversionnumber~^*(1)packageversion:*{"require":{"monolog/monolog":"1.0.*"}}1.0.*这意味着任何版本从1.0开始的开发分支，它将匹配1.0.0、1.0.2或1.0.20。(2)包版本：~~1.2相当于>=1.2,<2.0，即版本1，匹配前1位。1.~1.2只是表示.2部分可以改，而1.部分是固定的。（3）包版本：^^1.2.3相当于>=1.2.3<1.3，匹配前2位1.22.composerinstall（1）如果composer.lock已经存在，则读取composer.lock并下载依赖。(2)如果没有composer.lock文件，则读取composer.json文件，处理依赖，安装到vendor目录下。也就是说，如果你本地有一个composer.lock的副本，你可以保证无论过了多久，你都能够拉取相同的依赖。所以你应该把composer.lock放在git仓库中，这样你就可以保证你项目中的每个人和每台计算机，无论是什么系统，都可以拉取完全相同的依赖，以减少潜在的依赖对部署的影响。3.Composerupdate读取composer.json中指定的依赖，然后将依赖拉取到vendor目录，并将所有拉取的依赖的确切版本号写入composer.lock文件。(1)那么什么时候需要使用composerupdate呢？例如，当一个扩展发布的新版本有我们需要的新功能时，这时候我们就需要更新这个扩展。我们更新的时候指定具体更新的扩展名，比如composerupdatepackage，而不是直接composerupdate。因为直接composerupdate之后，所有的extensions都会更新，风险很大。4、总结：（1）composerupdate根据composer.json更新，扩展版本号写入composer.lock。(2)Composerinstall是根据composer.lock更新的(3)Composerupdate在开发过程中要少用，应该用composerinstall(4)如果添加新的包，可以使用：composerrequire"包名：版本号”
