虚拟包冲突源于provide或conflict声明引发的逻辑矛盾，如虚假声明提供扩展或过度冲突拦截，需通过composer show --platform和composer show -s排查，补全polyfill或降级冲突包解决。
Composer 虚拟包冲突不是“装不上某个包”，而是你声明了 provide 或 conflict，但 Composer 在求解依赖时发现逻辑矛盾——比如你声称自己“提供”了 ext-mbstring，却没真正装 polyfill，或两个包都声明 conflict 同一个东西，结果谁也装不了。
什么是虚拟包？provide 和 conflict 到底在干啥
虚拟包是 Composer 里不真实存在的包，只靠 composer.json 中的 provide 字段“假装存在”。典型用法：
-
"provide": {"ext-mbstring": "*"}：告诉 Composer “我（比如symfony/polyfill-mbstring）能替代原生扩展，别再检查系统有没有装” -
"conflict": {"laravel/framework": ">=11.0"}：硬性阻止安装某版本组合，哪怕它语法上合法
问题常出在：你手动加了 provide，但没确保运行时真能工作；或第三方包的 conflict 规则太宽，把你没用到的路径也封死了。这类冲突不会出现在 composer show --tree 里，因为虚拟包不进依赖树。
composer why-not 查不到虚拟包阻塞？试试这个组合
虚拟包不参与常规依赖链，composer why-not ext-mbstring 会返回空——它根本不是个真实包。正确做法是反向排查：
- 先跑
composer show --platform，确认当前 PHP 环境实际缺失哪些扩展（如ext-mbstring没启用） - 再查哪些已装包声明了
provide：运行composer show -s | grep "provide"，重点看symfony/polyfill-*、phpunit/phpunit、mockery/mockery这类高频“替身包” - 如果某个 polyfill 已装但
composer install仍报缺扩展，说明它没被识别——检查该 polyfill 的composer.json，确认其provide字段写的是"ext-mbstring": "*"，而不是"mbstring": "*"（少个ext-前缀就失效）
修复 provide 失效或 conflict 过度拦截
常见错误是直接删掉 provide 或关掉校验，这等于掩耳盗铃。真实可行的操作只有三类：
- 补全 polyfill：比如缺
ext-mbstring，就明确composer require symfony/polyfill-mbstring，别指望其他包“顺带提供” - 降级冲突包：如果
vendor/package的conflict锁死了整个生态，用composer show vendor/package查它支持的最低laravel/framework版本，然后composer require laravel/framework:^10.0 --with-dependencies - 临时绕过平台检查仅用于调试：
composer install --ignore-platform-reqs可以跳过provide校验，但必须立刻验证运行时是否真能跑通——比如调用mb_strlen()看会不会 fatal error
私有包加 provide 或 conflict 的坑
自己写的私有包如果加了 provide，务必确保两点：
- 它真的在
autoload里注册了对应函数/类，且不依赖未声明的扩展（比如你provide ext-curl，但代码里用了curl_init()，而系统没装ext-curl，照样崩） -
conflict字段只写明确定义互斥的组合，避免用"*"或模糊范围；例如"conflict": {"guzzlehttp/guzzle": ">=8.0.0 比 <code>"conflict": {"guzzlehttp/guzzle": "*"}安全得多
最易忽略的一点：虚拟包的约束是全局生效的——哪怕你项目里没 require 那个包，只要它的 conflict 规则匹配到其他已装包的传递依赖，Composer 就会拒绝解析。所以查冲突源头时，require-dev 里的包也得一起看。
