Composer 2.0 发布带来的性能优化、新特性和升级指南
Composer 在昨天程序员节这天发布了 2.0 版本，本次版本距离 Composer 1.0 beta 版本发布已经过去了 8 年之久，作为 PHP 包管理工具，八年时间内，Composer 给大象（PHP 的 Logo 是一头大象）装上了翅膀，为 PHP 项目开发带来了全新的扩展包（或者叫依赖包）安装和管理体验，降低它们维护成本的同时也极大丰富了 PHP 的生态系统。
本次新版本提供了很多新功能，更重要的是性能也有了大幅提升。如果感兴趣的话，你可以在 Composer GitHub 仓库查看详细的升级细节，这里学院君给大家简单介绍下新老版本在流行 PHP 项目中的性能对比、主要的新特性以及如何升级到 Composer 2.0。
性能优化
新版本从 Composer 和 packagist.org 之间使用的协议到依赖解析对几乎所有代码都进行了彻底的重构，包括使用 curl 并行下载文件和约束评估的优化（即扩展包的版本控制）等，这些重构使得 Composer 2.0 不论是速度还是内存使用方面都得到了大幅改进。
不过这些改进的真实表现取决于具体的使用场景，尽管官方在一些项目中得到了 50% 性能提升的报告，但是不能以此为据给出适用于所有场景的确切数字，不过可以肯定的是，如果你还没有使用 Composer 2.0，会对新版本的体验感到惊讶。
此外，require/remove 以及部分更新要比以前快得多，因为 Composer 现在只会加载修改过的扩展包对应的元数据。
下面是 Composer 1 和 Composer 2 在当前流行 PHP 项目中的速度优化对比：
可以看到，对于 Laravel 项目而言，性能提升了四倍左右。我自己体验了下使用新老版本初始化 Laravel 项目，确实肉眼可见的有了显著的速度提升。
主要新特性一览
我们简单概览下 Composer 2.0 的一些重要更新：
架构调整
对依赖更新内部执行的方式进行了重构，对你而言，现在可以看到更加确定性的更新，更新完成后，安装流程会自动并发执行，从而避免只安装到一半因网络问题导致流程被终止。
运行时新特性
vendor/autoload.php 初始化时新增了平台检测步骤，主要检查当前 PHP 版本和扩展包版本是否匹配，不匹配的话会初始化失败。
在 Composer 2.0 项目中，你可以在 vendor/composer 目录下看到一个新增的 InstalledVersions 类，它会在每个项目中自动加载并且在运行时有效，可以通过它来检查运行时项目中有效的扩展包及其版本号。
如果你的代码依赖这些运行时新特性，可以在 composer.json 的 require 配置项中添加 "composer-runtime-api": "^2.0" 依赖声明。
错误报告优化
Composer 2.0 优化了依赖不能被解析时错误报告的显示，现在的错误消息会更短、更清晰、更少重复。
带临时约束的部分更新
现在你可以运行 composer update vendor/package:1.0.* 升级指定扩展包（比如这里的 vendor/package）版本，它不会更新 composer.json，也不会更新 composer.lock 文件，如果你想添加这个临时约束的同时更新所有依赖，需要使用 composer update --with vendor/package:1.0.* 命令。
升级到 Composer 2.0
升级到 Composer 2.0 非常简单，只需要运行如下命令即可：
composer self-update --2
需要注意的是，升级后有些 Composer 1.0 版本的插件可能还没有支持 Composer 2.0，以及新的平台检测机制会检测运行时 PHP 版本和扩展包版本是否匹配，这些都有可能导致之前本来正常的扩展包依赖解析出现问题，你可以使用 composer self-update --rollback 或者 composer self-update --1 命令回滚到之前的老版本 Composer，或者阅读 Composer 升级指南了解更多细节。
