Composer虚拟包是通过provide字段声明抽象能力的非真实包，用于解耦依赖（如ext-pdo、psr/log-implementation），支持安装期环境检查与契约式依赖，但不保障运行时兼容性。
什么是 Composer 虚拟包（virtual package）
虚拟包不是真实存在的代码仓库，而是通过 provide 字段在 composer.json 中声明“我提供了某个抽象能力”，让其他包能依赖这个能力而不绑定具体实现。比如 ext-pdo、psr/log 是典型虚拟包——你不会 composer require psr/log 安装它，但会要求“我的包需要 psr/log-implementation”，然后由某个真实日志库（如 monolog/monolog）通过 "provide": {"psr/log-implementation": "1.0"} 来满足。
数据库驱动如何用 virtual package 声明
PHP 生态中，doctrine/dbal 和 laravel/framework 等项目都依赖数据库驱动的抽象契约，它们不硬编码 pdo_mysql 或 pdo_pgsql，而是依赖类似 php-pdo 或更细粒度的 ext-pdo-mysql 这类虚拟包。这些是 PHP 扩展级虚拟包，由 Composer 内置识别：
-
ext-pdo：表示系统已加载 PDO 扩展（基础能力） -
ext-pdo-mysql、ext-pdo-pgsql、ext-pdo-sqlite：表示对应驱动已启用
你在自己的包里要声明“支持 MySQL 驱动”，不是写 "require": {"pdo_mysql": "*"}（这会报错），而是写：
"require": {
"ext-pdo": "*",
"ext-pdo-mysql": "*"
}
Composer 会在安装时检查 php -m 输出是否含 pdo 和 pdo_mysql，不满足就中断并提示：Your requirements could not be resolved to an installable set of packages.
自定义数据库驱动虚拟包（如私有适配器）
如果你开发了一个非标准数据库驱动（比如对接某国产数据库的 PDO 封装扩展），想让它被其他包以契约方式依赖，就得自己定义虚拟包名，并让实现包主动 provide：
- 在驱动实现包（如
myorg/mydb-pdo-adapter）的composer.json中加：
"provide": {
"myorg/db-driver-implementation": "1.0"
}
- 在使用方（如 ORM 包）的
composer.json中声明依赖：
"require": {
"myorg/db-driver-implementation": "^1.0"
}
注意：这个虚拟包名必须全局唯一，不能和 Packagist 上已有包重名；且所有提供该能力的包都得一致使用该 provide 键，否则依赖无法解析。
常见踩坑点
虚拟包不解决运行时兼容性，只做安装期约束：
-
ext-pdo-mysql存在 ≠ MySQL 服务可连通，也不保证PDO::ATTR_ERRMODE设置正确 - 手动在
composer.json里写"provide": {"ext-pdo-mysql": "8.2"}是无效的——Composer 不允许覆盖内置扩展虚拟包 - 用
provide声明自定义虚拟包时，若多个包提供同一键但版本冲突（如 A 提供"1.0"，B 提供"2.0"），Composer 会报conflict，需靠conflict字段显式排除 - 本地开发调试时，
composer install --ignore-platform-reqs会跳过ext-*检查，掩盖环境问题
真正决定数据库能否工作的，是 php.ini 中扩展是否启用、DSN 是否合法、用户权限是否足够——虚拟包只是第一道门禁，别把它当运行时校验。
