1.composer 版本号 ~ ^ *
(1) 包版本：*

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

1.0.* 这表示任何从 1.0 开始的开发分支，它将会匹配 1.0.0、1.0.2 或者 1.0.22。

(2) 包版本：~

~1.3 相当于 >=1.3,<2.0， 即 1 版本，匹配前1 位 1.
~1.3 只意味着 .3 部分可以改变，但是 1. 部分是固定的。

(3) 包版本：^

^1.3.3 相当于>=1.3.3 <1.4 即匹配前2 位 1.3

2.composer install

（1）如果已经存在composer.lock时，读取composer.lock下载依赖。

（2）如果没有 composer.lock 文件，读取 composer.json 文件，处理依赖关系，并把其安装到 vendor 目录下。

也就是说本地有一份composer.lock，你就可以保证无论过去了多久，你都能拉到相同的依赖。
所以应该把 composer.lock 放到 git 版本库中，这样可以确保你项目中的每一个人、每一台电脑，不管什么系统，都能拉取到一模一样的依赖，以减少潜在的依赖对部署的影响。

3.composer update

读取composer.json中指定的依赖,然后拉取依赖放入vendor目录下，并且把所有拉取依赖的确切的版本号写入composer.lock文件中。

(1)那么什么时候需要使用composer update呢？
比如某扩展发布的新版本有我们需要的新功能时，这时我们需要更新该扩展，我们update时指定具体更新的扩展名，如composer update package 而不要直接composer update。因为直接composer update后，所有的扩展都会更新，风险很大。

4.总结:

（1）composer update 根据composer.json来更新的，并把扩展的版本号写入到composer.lock中。
（2）composer install 根据composer.lock来更新的
（3）开发过程中 少用 composer update ，应该用 composer install
（4）如果新加一个包，可以使用：composer require "包名:版本号"