Composer 2.0现已推出

更改和改进的列表很长，如果您有兴趣全部阅读，请查看完整的更改日志。我将在这里强调几个关键点。

从Composer和Packagist.org之间使用的协议到依赖项解析，包括使用cURL和约束求值优化并行下载文件，我们对几乎所有内容都进行了全面检查。这在速度和内存使用方面都带来了巨大的改进。不同之处取决于您的用例，所以虽然我在一些项目中看到这两个项目都有超过50%的改进，但我不能给出一个确切的数字。但我相信，如果你还没有尝试过作曲家2，你一定会大吃一惊的。

另外，需要/删除和部分更新现在要快得多，因为Composer现在只加载正在更改的包的元数据。

对内部完成依赖项更新的方式进行了重构，对您来说，这将导致更具确定性的更新。供应商目录的当前本地状态将不再干扰更新。

更新完成后，安装过程将自动运行，现在它将首先执行所有网络绑定操作-如果可能，还会并行执行。这将避免在安装过程中发生网络错误时留下更新了一半的供应商目录。

我们在初始化Vendor/autoload.php时添加了一个平台检查步骤，该步骤检查当前PHP版本/扩展与您的依赖项期望的版本/扩展是否匹配，否则将严重失败。

有一个新类Composer\InstalledVersions，它会自动加载到每个项目中，并在运行时可用。它允许您检查在您自己的项目运行时存在哪些包/版本。

如果您的代码依赖于这些运行时功能中的任何一个，则应该在您的Composer.json中要求"；Composer-Runtime-API"；："；^2.0"；。这是一个由Composer提供的虚拟软件包，它将确保人们必须使用Composer 2.x来安装您的软件包。

因为事情并不总是按照它们应该的方式进行，所以我们确保改进了在无法解决依赖关系时向您显示的错误报告。在这里很难给出具体的例子，因为有一百万种方式可能会失败，但你会很有希望地注意到，现在的信息更短、更清晰、重复性更少。

有时，将单个软件包升级或降级到特定版本可能很有用，可能是为了临时测试某些东西或等待错误修复。例如，您现在可以运行Composer update vendor/package：1.0.*(或1.0.12或任何其他版本约束)，以便仅将供应商/包更新到与此附加约束匹配的版本。这不会更新Composer.json中的需求，也不会将锁定文件标记为过期。

如果您想要添加/限制约束，但仍然对所有依赖项进行完全更新，您可以使用update--with vendor/package：1.0.*，它将使用该附加约束来运行更新。

我们的目标是让每一位作曲家用户都能顺利、快速地升级。收益是巨大的，我们希望每个人都能从中受益。为了实现这一目标，我们做了几件事：

Composer.lock文件可以在不同版本之间互操作，因此您可以升级到2.0并在需要时轻松回滚。

大多数命令和参数都保持不变，在2.0中，您对Composer的了解在很大程度上仍然是正确的。

如果您从1.x运行Composer Self-update，它将警告您有一个新的稳定的Composer主版本可用，您可以使用Composer Self-update--2迁移到它。

如果您遇到问题，您可以使用Composer Self-update--1随时返回。希望这会让每个人都感到舒服，可以尝试新的版本。

如果您正在从安装程序脚本自动安装Composer，并且希望暂时使用Composer 1.x，您还可以向其传递--1参数，以阻止其默认安装Composer 2.0。如果您这样做，请记住并以及时升级为目标，因为Composer 1.x的维护时间不会很长。

插件：对于大多数人来说，这可能是问题的主要来源。插件需要更新以支持Composer 2，其中一些还没有准备好。如果某个插件不支持Composer 2，它会抱怨并无法解决依赖关系，所以不必过多考虑，您可以试一试，看看它的运行情况。

新的平台检查功能意味着Composer会检查运行时PHP版本和可用的扩展，以确保它们与项目依赖项匹配。如果发现不匹配，自动加载机将退出并显示错误详细信息，以确保不会忽略问题。要避免在部署到生产环境时出现问题，建议在构建或部署过程中运行Composer check-platform-reqs--no-dev和生产PHP过程。

存储库优先级：如果包存在于较高优先级的存储库中，则在较低优先级的存储库中将完全忽略该包。如果您在使用Composer 2时似乎缺少软件包，请参阅存储库优先级文档了解详细信息。

根据Composer 1.10中引入的警告，无效的PSR-0/PSR-4配置将不再在优化的自动加载器模式下自动加载。这些警告大多是针对那些本来不打算自动加载的类，所以我不认为会有大问题，但在升级之前清理这些会更安全。

如果您想了解更多，我强烈建议您阅读升级指南，其中有多个部分面向最终用户、插件作者和Composer存储库实现者。

我们不再有一个非常详细的功能路线图，因为2.0包含了大量的新功能，但是我想解释的一件重要的事情是我们未来对PHP版本的支持。

正如我在上面提到的，Composer 2.0支持PHP 5.3+，这在这一点上已经非常过时，并且使得代码很难在某些地方维护。我们努力确保每个Composer用户都能升级到Composer 2，但计划在未来的次要版本中取消对EOL PHP版本的支持。

Composer 2.1可能仍然支持PHP 5.3，这取决于时间线以及最终包含哪些功能，但是最晚到Composer 2.2，我们将放弃对PHP 7.1.3之前的所有内容的支持。根据我们的统计数据，这使得超过90%的Composer用户可以使用最新版本，对于其他坚持使用过时PHP版本的用户，我们将继续提供2.0.x或2.1.x范围内的重要错误和安全修复。

至于Composer 1.x，现在或多或少是停产了。如果出现任何问题，它也会收到重要的修复，但每个人的目标应该是尽快迁移到2.x。

最后，我要感谢每一位为实现这一目标做出贡献和帮助的人。2.0版本包括来自28个人的1100多个提交，150多个GitHub问题和拉请求，加上每个测试它、审查PR等的人。大约两年前的第一次提交是一项巨大的努力。

我还想感谢我们所有的私人包装商客户，他们帮助我们资助了这项工作，并为我们提供了时间来做这一切。我们真诚地希望每个人都能欣赏到这个结果！