鉴于Composer可以使用provide文件的virtual packages in provide部分，如果没有人负责，那么如何管理这些虚拟包的版本？
我的意思是，如果有人可以创建“evil”包，说明它是UI items - 特定的虚拟包（其中没有任何回购），而不是指定他们喜欢的任何版本。这可能会与其他“好”的包冲突，对吗？
答案 0 :(得分：1)
根据我的经验，这个“虚拟包”功能尚未被广泛使用，由于目前的实施方式，它肯定有其缺点。
如果你看看Packagist上的this search result，你会看到三个顶级软件包是psr/log（真正的接口软件包），psr/log（两个使用的虚拟软件包）其他真正的软件包，但方式错误）和psr/log-implementation（由大量软件包使用，包括monolog/monolog）。
这个例子说明人们会误解这个功能并做错事。您不能提供 psr/log，因为这是一个真正的包具有真正的接口定义。 需要 psr/log并且同时提供它更有意义。
您还正确地发现没有中央实体决定哪个版本的虚拟软件包应该存在，更不用说应该存在哪些虚拟软件包名称。这不是一个问题，因为决定真实包的名称是以同样的方式完成的：一个开发人员想到一个名字，就是这样。此过程不太可能产生非自愿冲突，因为通常Github帐户名称被用作供应商名称，而Github已经使它们成为唯一的。由于Composer用于命名包的一般结构，恶意冲突在现实世界中并不存在Jordi has pointed out in his blog。
返回虚拟包功能：有两篇博客文章讨论它。
第一个explains using this feature，其中包含上述虚拟psr/log-implementation包的示例。我不会在这里复制那个类似教程的文本。
关于虚拟包的整个方法的second (linked and replied to at the end of the first) discusses what's bad。
有些观点：
1）严格地说（如同代码编译），来自库本身的代码不需要提供
psr/log-implementation的包。它只需要LoggerInterface（恰好位于psr/log包中）。4）
5）有一天，有人可能决定引入另一个名为psr/log-implementation或任何虚拟包，作为一个包非常有问题。没有此虚拟包的定义。 [...]the-real-psr/log-implementation的虚拟包（他们可以轻松地做到这一点，对吧？）。此类软件包可以与现有的psr/log-implementation软件包完全交换，但为了有用，每个现有的PSR-3兼容记录器软件包都需要在其提供部分中提及该虚拟软件包。 [...]
由于所有这些问题和不确定性存在于良好的包装中，因此他们并没有真正使用此功能也就不足为奇了。
但是，你不能以你在问题中勾勒出来的方式滥用它。是的，任何包都可以声明它提供任何其他包。但就像它发生在psr/log一样，有一个声明它提供另一个包的包不会神奇地让每个人都下载该包。它的工作方式是一个包声明它提供了另一个包，并且通过要求这个包，虚拟包也被包含在内，并且将满足其他包的任何依赖性。虚拟包。
但是不要求包提供的东西会将其中的所有内容都排除在外。
为了包含不良软件，有人必须require。这最好是作为一个无辜的图书馆的间接依赖，并需要一个毫无戒心的开发人员的帮助，积极拉动此代码而不正确审查它。
这可能是我对所有事情的中心观点：如果你将某些代码插入到自己的项目中，请确保通过查看它来了解该代码的作用（这不仅是关于恶意事物，还包括基本代码质量，因为有一天你可能会被迫调试一个问题），或者确保你可以相信这个来源足以不对你做坏事。但是，您自己的代码库不受您不需要的软件包的影响（具有此类影响的最后一个错误是处理replace信息，但我现在没有找到该问题。）