Composer不支持虚拟包原生概念，所谓虚拟包实为通过replace、provide或conflict字段模拟行为：replace用于替代已内置功能的包（版本必须为"*"），provide用于声明兼容某规范（需真实实现和autoload），conflict用于阻止特定包安装。
Composer 不支持在 composer.json 中“定义虚拟包”——它没有虚拟包（virtual package）这个原生概念。所谓“虚拟包”，通常是开发者为解决依赖冲突、占位替换或条件注入而采用的变通手段，实际是靠 replace、provide 或 conflict 字段模拟行为，而非注册一个真实可安装的包。
为什么 require "foo/bar" 却不想装它？用 replace 消除依赖
常见场景：项目已内置某功能（如自研缓存驱动），但某个第三方包硬依赖 psr/cache 或 monolog/monolog，你又不希望 Composer 真去下载它。
这时可在主项目 composer.json 的 replace 字段中声明自己“替代”了该包：
{
"replace": {
"psr/cache": "*",
"monolog/monolog": "*"
}
}
效果是：composer install 时不再尝试安装被 replace 的包，也不会报错“未满足依赖”。但注意：
-
replace不提供自动加载，也不提供任何类——你得自己确保运行时有对应接口或实现 - 被 replace 的包若含
autoload或bin，这些能力全部丢失，不可替代其功能 - 不能写成
"psr/cache": "dev-main"，版本号必须是"*"或空字符串""，否则无效
想让别人 require 我的包，但不发布代码？用 provide 声明能力
provide 用于声明“本包提供了某接口规范的实现”，常用于抽象包（如 psr/log）的实现者。它本身不下载代码，只告诉 Composer：“我满足这个契约”。
例如，你写了一个轻量日志器，想声明它兼容 PSR-3：
{
"name": "acme/simple-logger",
"provide": {
"psr/log": "1.0.0"
},
"autoload": {
"psr-4": { "Acme\Logger\": "src/" }
}
}
这样下游项目 require "psr/log" 时，Composer 会认为该依赖已被 acme/simple-logger 满足（前提是它也被 require 进项目）。关键点：
-
provide必须配合真实可用的类和 autoload，否则只是空头支票 - 版本号要写准确，
"psr/log": "*"可能导致解析失败；建议写具体语义版本，如"1.0.0" - 不能靠
provide绕过 license 或安全检查——Composer 不校验实现是否真合规
conflict 不是虚拟包，但能阻止错误包被装进来
当你要明确禁止某包出现在依赖树中（比如避免旧版 guzzlehttp/guzzle 引发内存泄漏），用 conflict 是最直接的方式：
composer update
-
conflict不影响已安装的包，只作用于 update/install 阶段的依赖求解 - 它不提供替代方案，只是“拦停”——你需要同时在
require中指定安全版本，才能真正修复 - 别滥用：把整个组织名写成
"acme/*": "*"会导致所有包都被拒，毫无调试余地
真正容易被忽略的是：这三个字段（replace、provide、conflict）都只在当前项目的 composer.json 根层级生效，放进 extra 或嵌套对象里完全无效；而且一旦写错格式（比如多了一层花括号、用了单引号），Composer 会静默忽略，既不报错也不起效。
