Composer不支持同一包多版本共存，因PHP无运行时模块隔离机制，自动加载器仅注册vendor下单一路径，类名与命名空间强制唯一绑定。
Composer 不支持同一包的多个主版本共存。 这不是配置问题，是 PHP 语言层和 Composer 架构共同决定的硬限制：类名、命名空间、自动加载路径都唯一绑定到一个安装路径，vendor/monolog/monolog 下不可能同时存在 v1 和 v2 的代码。
为什么“多版本共存”在 Composer 里根本走不通
你看到 Node.js 的 node_modules/.pnpm 或 Python 的 venv 能隔离不同版本，但 PHP 没有运行时模块作用域机制。所有 require 和 autoload 都指向全局 vendor/ 目录下的单一路径。哪怕你手动把两个版本拷进去，composer dump-autoload 也只会注册最后写入的那个版本的 PSR-4 映射——另一个直接不可见。
常见误操作包括：
- 用
replace字段“假装”已提供某依赖，结果导致其他包的require被跳过，功能缺失 - 在
repositories里加多个同名包的不同分支，但 Composer 解析时仍只选一个满足全部约束的版本 - 试图通过
autoload-dev加载不同版本的测试工具，却忘了生产环境autoload.php不包含它们
composer why-not 是定位冲突的第一步
报错里只写 Conclusion: don't install guzzlehttp/guzzle:^8.0？别看结论，直接问谁在拦路：
composer why-not guzzlehttp/guzzle:^8.0
它会输出类似：
myapp/core dev-main requires guzzlehttp/guzzle (^7.5) laravel/framework ^10.0 requires guzzlehttp/guzzle (^7.2 || ^8.0)
这就暴露了真凶：你的根项目锁死了 ^7.5，而 Laravel 10 其实能接受 ^8.0，但 Composer 必须满足所有约束，所以只能卡住。
接着查是谁让根项目锁死 7.x：
composer why guzzlehttp/guzzle
结果常指向某个 SDK、私有包，或更隐蔽的 require-dev 工具（比如旧版 phpunit/phpunit 拉了 symfony/console v5，而它又强制 guzzle v7）。
放宽约束 or 替换包：两种解法的实际取舍
改 composer.json 不是目的，让整棵树能跑通才是。关键看谁可控、谁可弃：
- 如果你控制冲突来源（如内部包
acme/sdk），把它对monolog/monolog的约束从"1.26.1"改成"^1.26 || ^2.0"，再composer update acme/sdk - 如果冲突来自已归档的第三方包（如
aws/aws-sdk-php:2.x），别硬加--with-all-dependencies强升，直接换async-aws/s3或升级到aws/aws-sdk-php:3.x - 某些包用
conflict字段强互斥（如"conflict": {"laravel/framework": ">=11.0"}），即使你没装 L11，只要别的包间接拉进这个声明，Composer 就会拒绝解析
dev 包引发的冲突最容易被忽略
开发阶段的工具包（phpstan/phpstan、phpunit/phpunit、infection/infection）往往对 PHP 版本和底层依赖极其挑剔，且它们的约束会参与全局求解。但它们只该影响本地开发，不该拖累生产依赖。
快速验证是否是 require-dev 惹的祸：
- 临时删掉
composer.json中的require-dev块，再跑composer install --no-dev - 如果成功，说明冲突源就在 dev 工具链里；逐个恢复，用
composer why-not缩小范围 - 确认后，给这些工具单独锁版本（如
"phpstan/phpstan": "1.10.3"），避免它们随主依赖一起乱升
最麻烦的情况是：你删了 vendor 和 composer.lock，重装还是报错——那说明环境不一致（php -v 和 composer config platform.php 对不上）或约束本身就没交集，不是清缓存能解决的。
