Composer虚拟包是无源码的占位符，通过provide字段声明能力契约，如{"psr/cache-implementation": "*"}，使依赖该虚拟包的其他包能正常安装；它不生成文件、不触发自动加载，仅被Composer依赖求解器识别为已满足依赖。
Composer 虚拟包（Virtual Package）不是真实存在的代码包，而是一个“占位符”或“别名”，用来解决依赖冲突、提供能力契约、或替代已被弃用/拆分的包——它本身不带任何源码，只在 composer.json 的 provide 字段中声明。
虚拟包如何被识别和使用
Composer 在解析依赖时，会把 provide 字段声明的内容当作“已安装的包”来处理。比如一个包在 composer.json 中写：
{
"name": "mycompany/cache-adapter",
"provide": {
"psr/cache-implementation": "3.0.0"
}
}
这意味着：只要这个包被安装，Composer 就认为项目“提供了 PSR-6 缓存实现”，其他依赖 psr/cache-implementation 的包（如 symfony/cache）就能顺利安装，哪怕你没装 php-cache/cache 或 doctrine/cache 这类传统实现。
-
provide的键必须是合法的包名格式（含斜杠），值通常是版本号或* - 它不触发自动加载，也不生成文件到
vendor/；只是向 Composer 的依赖求解器“广播能力” - 不能单独
composer require一个虚拟包——它必须依附于某个真实包存在
常见用途：解决“包已拆分但旧依赖还锁着”的问题
当一个老牌包（如 monolog/monolog）被拆成多个子包（monolog/monolog, monolog/formatters, monolog/processors），老项目里可能还有 "require": {"monolog/monolog": "^1.0"}，但你想升级到新架构又不想改所有 use 语句。这时可让新包通过 provide 声明自己“兼容旧包”：
"provide": {
"monolog/monolog": "2.0.0"
}
这样 composer update 就不会报冲突，因为 Composer 认为“旧包需求已被满足”。
- 典型场景包括 Symfony 组件拆分、Laravel 的
illuminate/support替代整个laravel/framework子集 - 框架或 SDK 常用它做“向下兼容层”，避免用户被迫升级整套生态
- 注意：如果两个包都
provide同一个包名且版本不兼容，Composer 会报conflict错误
与 replace 和 conflict 的关键区别
别把 provide 和 replace 搞混：replace 是“我替换了那个包，你别装它了”，会阻止原包被安装；provide 是“我虽不是它，但我能干它的活”，允许共存。
-
replace：用于包名合并（如guzzlehttp/ringphp被guzzlehttp/guzzle替换后，后者用"replace": {"guzzlehttp/ringphp": "*"}） -
conflict：明确禁止某包某版本安装，常配合provide使用，比如“我提供 A，但和 B 的 v1 冲突” - 真实项目中，
provide很少手写，多见于官方维护的元包（meta-package）或接口规范包（如psr/log自身就providepsr/log-implementation）
为什么你几乎不需要自己定义虚拟包
除非你在维护一个 SDK、框架桥接层或企业级组件抽象层，否则直接写 provide 容易引入隐式依赖和调试困难。Composer 的依赖求解器对虚拟包的处理是静态的——它不校验你是否真实现了对应接口，只认声明。
- IDE 不识别
provide声明的能力，use Psr\Cache\CacheItemPoolInterface仍需手动确保有真实实现 -
composer show --tree里看不到虚拟包，composer depends也查不到谁依赖了它 - 最稳妥的做法：优先用真实实现包；仅当跨大版本迁移、或对接遗留系统时，才考虑用
provide撑过渡期
