虚拟包是仅含名称与约束的占位符，无源码、不占磁盘、不进vendor目录，用于声明能力已由其他方式提供；常见于PHP扩展、PSR接口实现及依赖冲突规避。
虚拟包（virtual package）根本不会被安装
Composer 中的 virtual package 不是真实存在的包，没有源码、没有 composer.json、不占磁盘空间，也不会出现在 vendor/ 目录里。它只是一个“名字+约束”的占位符，用来声明「某类能力已由其他方式提供」。
常见场景包括：
- 系统级扩展：比如
ext-gd、ext-curl这类 PHP 扩展，本身不是 Composer 包，但某些包在require里写了"ext-gd": "*"，Composer 就会把它当作一个虚拟包去校验 - 替代实现：如
psr/log是接口规范，monolog/monolog和symfony/debug都能提供其实现；你可以在replace字段里写"psr/log": "1.0.0"，表示当前包已“提供”该虚拟包 - 避免冲突：Laravel 的
laravel/framework在replace中声明了"illuminate/support": "^10.0"等，防止用户手动 require 同名包导致版本错乱
replace 和 provide 的行为差异很关键
replace 是“我替换了你”，一旦声明，Composer 就不会再装被替换的包——哪怕你在 require 里显式写了它，也会被静默忽略。而 provide 是“我能提供这个能力”，只影响依赖解析，不阻止安装。
容易踩的坑：
- 用
replace错误覆盖了需要运行时代码的包（比如把guzzlehttp/guzzle替换成空字符串），会导致Class not found -
provide声明的版本号必须严格匹配下游依赖的require，否则无法满足约束，例如下游要"psr/http-client": "^1.0"，你provide了"psr/http-client": "0.9"就无效 - 虚拟包不参与自动加载，
autoload里写的psr-4路径对它完全没用
错误信息里出现 virtual package 多半是环境或约束问题
当你看到类似 Your requirements could not be resolved to an installable set of packages，并附带 ... but these conflict with your requirements or minimum-stability，其中提到 ext-mbstring 或 psr/container 这类名字，基本可以判定是虚拟包约束未满足。
排查步骤：
- 运行
php -m确认扩展是否真实启用（注意 CLI 和 Web SAPI 的 php.ini 可能不同） - 检查
composer.json里的config.platform是否伪造了不存在的扩展，比如"ext-imagick": "3.5.0"但实际没装 ImageMagick - 用
composer show --platform查看 Composer 当前识别到的平台能力，它比php -v和php -m更贴近 Composer 自己的判断逻辑 - 如果项目跑在 Docker 里，确认基础镜像是否包含对应扩展，
php:8.2-cli默认不含ext-pdo_mysql
真实软件包的文件结构和加载机制不可绕过
一个真实包（如 symfony/console）一定有：
-
vendor/symfony/console/composer.json—— 定义其元信息与依赖 -
vendor/symfony/console/Symfony/Component/Console/—— 实际 PHP 类文件 -
vendor/autoload.php里注册了它的 PSR-4 自动加载规则
而虚拟包连 vendor/ 目录下都不会有对应子目录。想靠 composer require xxx/virtual 来“假装装了某个东西”是行不通的——Composer 会直接报 Could not find a matching version，因为它压根不收录这类名字。
最常被忽略的一点：虚拟包的约束检查发生在 composer install 或 composer update 阶段，但它的失败可能直到 require vendor/autoload.php 时才暴露，尤其是 platform 伪造不一致 + 自动加载阶段平台检测启用（Composer 2+ 默认开启）的情况下。
