虚拟包是无代码的占位符，仅用于依赖声明；Composer 不提供自动 fallback 或默认实现机制，必须由真实包通过 provide 显式声明能力，且项目根 composer.json 的 provide 字段被完全忽略。
Composer 虚拟包（virtual package）本身不提供实现，它只是个占位符；所谓“默认实现”必须靠 replace 或 provide 显式声明，并由真实包主动绑定——没有自动 fallback 机制。
什么是虚拟包，为什么不能直接“设置默认实现”
虚拟包（如 ext-redis、psr/log、phpunit/phpunit）在 composer.json 中只以字符串形式出现在 require 里，它们本身没有代码、不发布到 Packagist，也不含 autoload。Composer 只是用它做依赖检查和冲突检测。
你写 "psr/log": "^3.0"，不代表 Composer 会自动装某个具体实现；它只表示：“我需要一个能提供 psr/log 的包”。是否装、装哪个，完全取决于你显式 require 的真实包（比如 monolog/monolog）是否通过 provide 声明了该能力。
- 虚拟包不能被
composer require直接安装 -
composer install不会为你选“默认实现”——它只报错：找不到提供该虚拟包的已安装包 - 没有配置项（如
config.default-provider）可设“默认实现”，这不属于 Composer 的设计范畴
如何让项目“自动用上”某个实现（常见场景）
典型需求是：声明依赖 psr/cache，但希望默认走 symfony/cache，而不是每次都要手动 require symfony/cache。
可行做法只有两种，且都需在项目级 composer.json 中操作：
- 在
require中**同时列出虚拟包和具体实现**："psr/cache": "^3.0","symfony/cache": "^6.4"
只要symfony/cache的composer.json包含"provide": {"psr/cache": "^3.0"}（它确实有），Composer 就认为依赖满足 - 用
replace声明本项目“替代”虚拟包（仅限自身包）：
如果你正在开发一个 SDK，想声明“我这个包本身就实现了psr/http-client”，就在它的composer.json里写："replace": {"psr/http-client": "*"}
注意：replace是对当前包自身的声明，不是为别人设默认
为什么 provide 必须写在真实包里，不能由项目配置注入
Composer 在解析依赖图时，会扫描每个已知包的 composer.json 中的 provide 字段，构建“谁提供了什么”的映射表。这个过程发生在 lock 文件生成阶段，且完全基于静态文件内容。
项目根目录的 composer.json **不支持**在 config 或 extra 里动态添加 provide 声明。以下写法无效：
{
"config": {
"provide": {"psr/log": "^3.0"} // ❌ Composer 忽略
}
}
同样，extra.installer-paths、repositories、环境变量等也都无法注入虚拟包实现关系。
真正起作用的 provide，必须存在于你 require 的那个真实包的原始 composer.json 中——比如查看 monolog/monolog 的源码，就能找到 "provide": {"psr/log": "^1.0 || ^2.0 || ^3.0"}。
容易踩的坑：以为 conflict 或 replace 能控制“优先级”
有人试图用 conflict 排除其他实现，或用 replace 覆盖别的包，来“强制指定默认”：
-
"conflict": {"zendframework/zend-log": "*"}—— 只阻止安装，不解决“谁来提供” -
"replace": {"psr/log": "*"}写在项目里 —— 无效，项目不是可提供能力的包 - 给两个都提供
psr/cache的包同时require（如symfony/cache和laravel/framework）—— Composer 不报错，但运行时行为取决于自动加载顺序，不可控
最终决定权始终在 PHP 自动加载器（vendor/autoload.php）和类定义顺序上，Composer 只管“有没有”，不管“用哪个”。
