virtual包是provide字段声明的逻辑占位符，如"ext-gd": "*"，仅向SAT求解器声明某扩展或接口已实现，不安装代码、不参与版本解析，仅满足require约束；错误使用无法解决真实依赖冲突。
Composer 虚拟包（virtual packages）不是“解决”依赖冲突的银弹，而是绕过平台约束或模拟扩展/功能缺失的声明手段；它不修改实际依赖图，只影响 SAT 求解器对「require」条件的满足判断。
什么是 virtual 包？它根本不是真实包
virtual 包是 composer.json 中 provide 字段声明的一类逻辑占位符，例如：
"provide": {
"ext-gd": "*",
"psr/log-implementation": "1.0.0"
}
它告诉 Composer：“本包（比如 symfony/polyfill-gd）能提供 ext-gd 的全部功能”，从而让其他依赖 ext-gd 的包认为该扩展已就绪。它不安装任何东西，也不参与版本解析——只是在 SAT 求解阶段把 "require": {"ext-gd": "*"} 这个约束标记为“已满足”。
常见虚拟包类型包括：
-
ext-*：如ext-mbstring、ext-xml，用 polyfill 替代 -
psr/*-implementation：如psr/log-implementation，声明当前项目已提供日志实现 -
php本身（极少见，慎用）
什么时候该用 provide？典型场景只有两类
你只有在以下两种情况才应主动加 provide：
- 项目已通过 polyfill 或自研代码实现了某个扩展/接口，但依赖链中某包硬性
require它（如intervention/image要求ext-gd，而你用symfony/polyfill-gd模拟） - 你想让多个日志库共存（如
monolog和psr/log实现），需显式声明一个psr/log-implementation，否则某些包会因找不到实现而报错
别用它掩盖真实冲突：如果 package-A 要求 symfony/console:^5，而 package-B 要求 symfony/console:^6，加 "provide": {"symfony/console": "*"} 不会起作用——provide 不替代包版本，只替代「扩展名」「接口名」这类无版本语义的标识符。
provide 写错的三个致命坑
写 provide 很容易让问题更糟，尤其注意：
- 值必须是字符串，不能是数组或布尔值：
"provide": {"ext-gd": "*"}✅，"provide": {"ext-gd": true}❌（Composer 直接忽略） - 提供的名称必须与被 require 的完全一致：写成
"ext-gd-dev"或"gd"都无效，必须是ext-gd - 它不解决运行时兼容性：即使你
provide ext-gd，但代码里真调用了imageantialias()（PHP 8.0+ 才有），而 polyfill 没实现，运行时仍会 fatal error
验证是否生效：运行 composer show --tree | grep "ext-gd"，若看到 (provided) 出现在某包后，说明声明已被识别；若没出现，检查拼写、是否在正确包的 composer.json 里（通常是 polyfill 包自己声明，而非你的根项目）。
替代方案比 provide 更常用：用 replace 处理包级替代
如果你真正想做的是“用 A 包替代 B 包”，比如用 laravel/sanctum 替代 laravel/passport 提供的 API 认证能力，应该用 replace 字段，而不是 provide：
"replace": {
"laravel/passport": "*"
}
这会告诉 Composer：“装了我，就别再装 laravel/passport”，从而避免两者同时存在引发的类名冲突或服务注册覆盖。注意：replace 是硬性排除，且被替换的包不会出现在 vendor/ 中；而 provide 是软性满足，不阻止安装。
最关键的提醒：virtual 包机制只在「约束层」起效，它无法修复已损坏的 composer.lock，也不能跳过 PHP 版本不兼容这种底层事实。一旦你发现加了 provide 后 composer why-not 输出没变，说明冲突根源压根不在这个维度——该回去看 composer why-not vendor/package:version 的第一行输出，找那个真正的上游封杀者。
