symfony2 使用composer update命令之后，不动了，怎么解决

遇到过相同的问题,我的解决方案是在`.gitignore`文件里面把`composer.lock`这一行去掉,也就是说把`composer.lock`文件也加入版本控制.这样做有以下好处:让参与项目开发的成员使用这些package的同一版本,减少分歧;在生产环境下,使用命令`composerinstall`可以确保跟开发的时候使用了统一的版本,减少不必要的变数;跟踪当前项目使用所有`package`的版本,当执行`composerupdate`出现问题时,可以利用Git定位到出问题的package,匹对下版本,接下来就可以做如:在composer.json里面写死版本等的解决动作了.注意:这里说下composer的机制,当`composer.lock`文件存在的时候,执行`composerinstall`命令时,composer会更新按照`composer.lock`里的package指定版本进行安装,如果是执行`composerupdate`的话,会更新`package`版本,并更新`composer.lock`文件.最后一条好处尤其重要,设想如果是在没有版本控制`composer.lock`文件的情况下,一出现问题,那就直接瞎眼了.

要明白是什么影响了Composer的运行速度，必须先理解Composer的运行原理。Composer的大致运行步骤如下：

1. 分析你的composer.json文件，找到所有需要安装的第三方软件的名称和对应的版本号

2. 从本地缓存目录和Packagist服务器获取上述的第三方软件的信息，包含最新版本，代码存放地址等等

3. 分析依赖关系，根据包依赖、版本是否有更新等条件计算出最终需要安装的第三方软件的清单

4. 根据这份清单下载第三方软件的源代码，根据参数的不同，下载方式会是用GitClone项目或者是直接下载Zip包

5. 将第三方软件安装到本地，一般是安装在项目下的./vendor目录，同时根据参数生成用于载入第三方软件的autoload文件分析：从上述步骤中可以看到Composer在运行时会有5个不同的阶段，而其中1、2、3、4步都是会因为各种原因导致Composer执行速度缓慢的，类似composer-proxy.com这样的Composer镜像/代理站其实已经解决了第1、2步骤速度慢的问题，也就是加快从Packagist下载版本更新定义文件慢的这一步。而3这一步由于PHP的运行效率所限制，加上计算依赖的算法又特别复杂，所以如果用的第三方软件特别多，就特别容易造成内存不足、超时、运行缓慢等问题。测试基于6个项目进行composerupdate--dry-run得出，可以看到使用了HHVM之后速度从2分14秒提高到了34秒，平均6秒就完成一个项目的composerupdate，可见速度提升是非常大的。