虚拟包是通过replace或provide声明的逻辑包，非真实发布：replace完全替代原包并忽略其文件与依赖，provide仅声明接口实现而不阻止原包安装；必须在实际发布的包中声明，且需严格按契约使用以避免依赖解析错乱。
虚拟包（virtual package）不是真实发布的包，而是通过 replace 或 provide 声明“假装存在”的包名，用于解决冲突、占位或解耦依赖契约。团队若误用，轻则 composer install 失败，重则导致依赖解析错乱、CI 构建不一致——它不是语法糖，而是依赖图谱的“声明式补丁”，必须按契约使用。
什么时候该用 replace 而不是 provide
replace 表示“我完全替代这个包”，Composer 会彻底忽略被替换包的任何文件和依赖；provide 表示“我实现了这个包的接口能力”，但不替代其代码，原包仍可被安装（除非被其他规则排除）。
- 用
replace：内部封装了monolog/monolog的定制日志组件，且明确禁止项目再装原版（避免自动加载冲突） - 用
provide：你写了一个 PSR-3 兼容的日志实现，想让其他包（如symfony/console）能识别它为日志服务，但不阻止用户同时装monolog - 错误用法：在
replace中填一个不存在的包名（如"replace": {"vendor/ghost-package": "*"}），这不会报错，但会让依赖解析器困惑，尤其当其他包require它时可能选错路径
composer.json 中声明虚拟包的实操细节
虚拟包声明必须出现在实际发布的包里（即你自己的 mycompany/logger 的 composer.json 中），不能只写在主项目里——否则对其他依赖它的项目无效。
-
replace字段值必须是字符串或对象，支持版本约束："replace": {"monolog/monolog": "^2.0"}比"*"更安全，避免意外覆盖不兼容版本 -
provide不支持版本约束，只能写包名："provide": {"psr/log-implementation": "1.0"}（注意：这里的"1.0"是语义标签，非真实版本号） - 若同时声明
replace和require同一包（如"replace": {"monolog/monolog": "^2.0"}, "require": {"monolog/monolog": "^2.0"}），Composer 会静默忽略require——这是设计行为，不是 bug，但容易让人误以为依赖还在
协作中踩得最多的三个坑
虚拟包的问题往往在多人协作、多项目复用时集中爆发，因为它的影响是隐式的、跨项目的。
- 本地开发能跑，CI 失败：主项目
composer.json里写了replace，但没提交到 Git；或者 CI 使用了缓存的vendor，而新引入的虚拟包没触发重新解析 - 升级后功能异常：某包从
provide改成replace，下游项目没改autoload映射，导致类找不到——因为replace后 Composer 不再加载原包的autoload规则 - 私有源同步失败：Satis/SatisPress 等私有仓库不默认索引
replace和provide字段，需显式启用"archive": {"skip-dev": true}并确保元数据生成完整
最易被忽略的一点：虚拟包不改变自动加载逻辑本身，只影响依赖解析结果。也就是说，replace 掉一个包，并不会自动把你自己的类映射过去——你仍要靠 autoload 配置把命名空间对上，否则 Class not found 错误照常出现。
