虚拟包是依赖管理中的逻辑占位符，不包含实际代码，仅通过provide字段声明接口契约；Composer校验时会匹配任意实包提供的该能力，从而实现解耦与可替换性。
什么是虚拟包（virtual package）？
虚拟包不是真实存在的、可下载的代码包，而是一个「占位符」或「接口契约」，用于表达“只要某个包提供了某项能力，就视为满足依赖”。它不包含源码，也不在 Packagist 上发布，只出现在 composer.json 的 provide 字段里。
为什么 require 一个虚拟包不会报错？
因为 Composer 在解析依赖时，会检查所有已安装包的 provide 声明——只要任意一个真实包声明了 "provide": {"psr/log": "^3.0"}，那 require 中写 "psr/log": "^3.0" 就能通过校验。常见例子：
-
monolog/monolog提供psr/log -
phpunit/phpunit提供phpunit/php-invoker（旧版） - Laravel 的
illuminate/support提供psr/simple-cache
你 不能 执行 composer require psr/log 来安装它，它本身不可安装；但你可以 require 它，Composer 会去找谁“提供”它。
如何查看哪些包提供了某个虚拟名？
运行以下命令，列出当前项目中所有声明了 provide 的包及其提供的虚拟名：
composer show --provides | grep 'psr/log'
或者更直接地看整个提供关系图：
composer depends psr/log --tree
注意：composer depends 默认只查真实包，要查虚拟包需加 --tree 或确保目标名已被某个包 provide 过，否则会提示“no package provides…”。
自己定义虚拟包容易踩什么坑？
除非你在开发框架级组件或做兼容层封装，否则一般不需要手动写 provide。常见误用点：
- 在应用项目的
composer.json里加"provide": {...}—— 没意义，虚拟包是给其他包“消费”的，不是给自己用的 - 提供了一个不存在的虚拟名（如拼错
psr/http-message），下游依赖无法匹配，导致安装失败 - 版本号写得太宽（如
"psr/container": "*"），可能掩盖真实兼容性问题 - 没同步更新
autoload或接口实现，光声明provide不代表功能可用
虚拟包的价值不在“声明”，而在“解耦”：它让日志、缓存、HTTP 抽象等能力变成可替换的契约，而不是绑定到某个具体实现上。这点在写可插拔组件时最关键，但多数业务项目只需理解它怎么被别人用，不必亲手造。
