Composer虚拟包是通过replace或provide声明的逻辑占位符（如psr/log），不带实际代码，仅用于满足require约束；常见于polyfill包或PSR接口实现，但多个provide共存时Composer仅取首个满足项，易导致冗余依赖。
什么是 Composer 虚拟包（virtual package）
虚拟包不是真实可下载的包，而是由 replace 或 provide 字段声明的“逻辑占位符”，比如 psr/log、ext-zip、php。它们本身不带代码，只用于满足其他包的 require 约束。常见于 polyfill 包（如 symfony/polyfill-mbstring）或抽象接口实现（如日志、缓存、事件等 PSR 标准）。
为什么虚拟包会导致重复安装？
当多个包都 provide 同一个虚拟包（例如 psr/log），而你又没显式约束实现类，Composer 可能按解析顺序选中较重的实现（比如 monolog/monolog 而非轻量的 php-pm/psr-log-adapter），导致本可避免的依赖被拉入。
- 多个
provide声明共存时，Composer 不做“最优解”筛选，只取第一个满足条件的实现 -
replace字段若写成"monolog/monolog": "*"，会阻止安装，但不提供任何类——运行时报Class not found - 框架默认 require 的虚拟包（如 Laravel 的
psr/container）可能被多个扩展间接提供，造成冗余传递依赖
如何精准控制虚拟包的实现选择
关键不是“避免提供”，而是“明确指定唯一实现”。靠删包或模糊约束只会让 Composer 更难收敛。
- 在
composer.json的require中显式声明你要的实现，例如："psr/log": "^3.0"+"monolog/monolog": "^3.0"，而不是只留前者 - 用
conflict主动排除你不想要的实现，例如："conflict": {"graylog/graylog-php": "*"}，防止它通过传递依赖带入monolog - 检查
composer show psr/log，确认当前实际被加载的是哪个包；再用composer why-not monolog/monolog:2.13.0看是否被某条链阻断 - 对 polyfill 类虚拟包（如
ext-iconv），优先用symfony/polyfill-iconv并加"replace": {"ext-iconv": "*"}，但必须确保该 polyfill 真正覆盖了所有调用路径
容易被忽略的陷阱：provide 不等于可用
provide 是声明“我能代替谁”，但不保证 API 兼容或功能完整。比如 slim/slim 也 provide psr/http-message，但它只提供部分接口，和 guzzlehttp/psr7 并不等价。运行时若调用到缺失方法，就会报错。
真正难判断的，是某个 provide 是否被项目代码或框架底层直接依赖——不能只看 composer depends，得结合 grep -r "new ServerRequest" . 或 Xdebug 断点确认实际调用栈。一旦误删，错误往往延迟到特定请求才暴露。
