Virtual Package 是 composer 中仅用于依赖解析的占位符，无实际文件，通过 provide 字段声明已提供某扩展（如 “ext-gd”: “8.2.0”），需与 require 中对应条目共存，仅绕过安装检查，不解决运行时缺失问题。
Virtual Package 是什么，为什么它不真存在
Composer 的 virtual package 不是真实发布的包，而是一种“占位符”——它没有源码、没有 composer.json、也没有任何文件，只在依赖解析阶段被当作一个合法的包名来参与版本约束和冲突检测。它的唯一作用是：让 Composer 相信某个能力“已经存在”，从而跳过安装真实包。
典型场景就是 php 扩展：比如项目声明需要 ext-gd，但你不想（或不能）通过 pecl install 或系统包管理器装 GD 扩展，而是想用纯 PHP 实现（如 libgd 的封装库）或干脆在 CI 中跳过扩展检查。这时，你可以声明一个 virtual package 来“欺骗” Composer。
如何声明 virtual package 替代 ext-* 依赖
关键不是去定义 virtual package 本身，而是让 Composer 认为某个扩展已满足——这通过 provide 字段在项目或本地包的 composer.json 中完成。
- 在你的项目根目录
composer.json的require中写上扩展名，例如："ext-gd": "*" - 在同一份
composer.json的provide字段中声明你“提供”了它：{ "provide": { "ext-gd": "8.2.0" } } - 执行
composer update后，Composer 就不再报ext-gd is missing错误，也不再尝试安装任何真实扩展
注意：provide 的版本号可以任意写（如 "*" 或 "0.0.0"），只要格式合法；Composer 只校验是否提供了该包名，不校验版本真实性。
常见踩坑点：provide 写在哪？require 还要留吗？
provide 必须写在**当前项目或你控制的某个已安装包**的 composer.json 里，不能写在 composer.lock 或远程包中（那无法生效）。而且：require 中的 ext-* 条目必须保留，否则 Composer 根本不会触发扩展检查逻辑——provide 是用来“满足”它，不是替代它。
- 错误做法：删掉
"ext-mbstring": "*"，只加provide→ Composer 完全忽略该扩展要求 - 正确做法：同时存在
require和provide，且二者包名严格一致（包括大小写） - 如果用的是第三方库（如
symfony/polyfill-mbstring），它本身已在内部provide了ext-mbstring，此时你只需require该 polyfill，无需手动加provide
Virtual package 不能解决运行时缺失的问题
它只绕过 Composer 的依赖检查，不改变 PHP 运行时行为。如果你代码里直接调用了 gd_info()，而系统真没装 GD 扩展，运行时仍会报 Fatal Error: Uncaught Error: Call to undefined function gd_info()。
所以真正安全的做法是：
- 优先使用
symfony/polyfill-*等兼容层（它们用纯 PHP 模拟扩展函数） - 仅在测试/CI 环境中用
provide绕过检查（配合extension_loaded()运行时判断做降级） - 永远别在生产环境靠
provide声称有扩展，却实际没装
virtual package 是个解析期开关，不是运行时补丁。漏掉这点，很容易在部署后才发现函数根本不存在。