Composer虚拟包是用于声明“某功能已被本项目提供”的占位符，通过replace字段替代真实包（如"monolog/monolog": "*"），要求name与被替代包名一致；它不下载代码，仅影响依赖解析，且需自行配置autoload——provide字段才是声明抽象能力（如"psr/log-implementation": "3.0.0"）的推荐方式。
什么是Composer虚拟包？
Composer虚拟包不是真实存在的库，而是一种“占位符”声明，用来告诉Composer：某个功能或接口已被当前项目或环境提供，无需再安装对应的实际包。典型场景是框架插件、SaaS平台扩展、或系统级组件（比如ext-redis已启用时，避免重复安装phpredis/phpredis）。
它不下载任何代码，也不生成vendor/下的文件，只影响依赖解析逻辑——比如解决“无法安装A包，因为它和B包冲突”，而你其实只需要A的接口契约，自己已实现。
replace字段怎么写才生效？
虚拟包靠replace在composer.json中声明。它不是添加依赖，而是“声明替代”。必须满足两个条件才会被识别为虚拟包：
-
name字段必须与被替代包的完整包名完全一致（如"monolog/monolog"） -
replace字段里要显式列出该包名，并配任意版本号（如"monolog/monolog": "*"）
示例（项目自身实现了Monolog接口，不希望安装官方包）：
{
"name": "myapp/core",
"replace": {
"monolog/monolog": "*"
}
}
注意：replace不会自动加载类；你要确保自己的实现已通过autoload正确注册，否则运行时仍会报Class not found。
为什么require里写虚拟包名没用？
直接在require里写"monolog/monolog": "*"，Composer会去Packagist找真实包并尝试安装——这不是虚拟包的用法。虚拟包必须由**被依赖方**主动声明replace，才能让依赖它的其他包“认为该依赖已满足”。
常见误操作：
- 在项目
composer.json的require中写"psr/log": "^3.0"，以为能“虚拟提供日志接口”——错，psr/log是规范包，本身不含实现，必须由具体日志库提供 - 漏写
name字段，导致replace被忽略（Composer要求虚拟包必须有合法name） - 版本约束写成
"*"以外的形式（如"^2.0"），但实际项目只实现了PSR-3，不兼容Monolog v2的私有API——这会造成运行时隐性失败
虚拟包和provide有什么区别？
provide才是标准的“能力声明”字段，专用于声明本包提供了某个抽象能力（如"psr/log-implementation": "3.0.0"）。它不绑定具体包名，更安全、更语义化。
对比：
-
replace：硬替换某包，适合“我就是那个包”的场景（比如fork后重命名发布） -
provide：软声明能力，适合“我实现了这个接口”，推荐用于PSR规范、驱动接口等
如果你只是想让symfony/console这类依赖psr/log的包顺利安装，正确做法是在composer.json中加：
"provide": {
"psr/log-implementation": "3.0.0"
}
而不是用replace去碰psr/log本身——后者可能破坏其他包对PSR接口版本的判断逻辑。
最易被忽略的一点：虚拟包不解决自动加载问题，也不改变vendor/autoload.php的行为；所有类路径仍需你自己通过autoload配置好，否则class_exists()会返回false，哪怕Composer认为依赖已“满足”。
