虚拟包是Composer中代表能力或接口的逻辑包名，如psr/log-implementation；通过provide字段声明本包提供该能力，可满足依赖并实现替换，避免冲突。
Composer 的 "provide" 字段用于声明当前包“提供”某个虚拟包或接口的实现，从而解决依赖冲突或实现接口替换。它不下载任何代码，只是告诉 Composer：本包已经包含了某个功能的实现，可以替代其他包的需求。
什么是虚拟包？
虚拟包是 Composer 中一种逻辑上的包名，不代表真实存在的库，而是代表某种能力或接口规范。例如：
- psr/log-implementation：表示实现了 PSR-3 日志接口
- psr/http-message-implementation：表示实现了 PSR-7 HTTP 消息接口
这些虚拟包本身没有代码，但其他包可以用它们作为依赖，表示“我需要一个实现了该接口的库”。
如何使用 "provide" 实现虚拟包声明？
在你自己的包中，如果你实现了某个接口，就可以通过 provide 声明你提供了对应的虚拟包。
例如，你的日志库实现了 Psr\Log\LoggerInterface，可以在 composer.json 中这样写：
{
"name": "your-vendor/awesome-logger",
"require": {
"psr/log": "^3.0"
},
"provide": {
"psr/log-implementation": "3.0"
}
}
这样，当其他包要求安装 psr/log-implementation 时，Composer 会认为你的包满足这个需求。
实现接口替换（互斥包的替代）
多个包可能提供相同的功能，比如不同的缓存后端、日志实现等。通过 provide 可以实现“谁安装了，谁就代替了接口”。
典型场景：A 包和 B 包都实现了同一套接口 C，项目只需要其中一个。
假设有一个包依赖于 cache-implementation 虚拟包：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
{
"require": {
"your-vendor/cache-implementation": "*"
}
}
你可以有两个实现：
实现一：Redis 缓存
{
"name": "your-vendor/redis-cache",
"provide": {
"your-vendor/cache-implementation": "1.0"
}
}
实现二：Memcached 缓存
{
"name": "your-vendor/memcached-cache",
"provide": {
"your-vendor/cache-implementation": "1.0"
}
}
项目只需安装其中一个，就能满足对 your-vendor/cache-implementation 的依赖。两者不会同时被要求安装，避免冲突。
结合 "replace" 和 "conflict" 更精确控制
有时你还想表达“我这个包就是某某包的替代品”，可以配合使用：
- replace：表示当前包替代另一个包（防止重复安装）
- conflict：表示不能和其他包共存
例如，一个 Laravel 应用的定制版想替代原版：
{
"name": "your-company/laravel-custom",
"replace": {
"laravel/framework": "self.version"
},
"provide": {
"laravel/framework": "self.version"
}
}
这样既防止原版被重复安装（replace），又让依赖 Laravel 的包能正常工作（provide）。
基本上就这些。provide 的核心作用是“声明能力”，让 Composer 知道这个包可以充当某种角色，从而灵活支持插件机制、接口实现替换和多后端选择。不复杂但容易忽略。
