composer 不支持 guzzle 多个主版本共存，因命名空间冲突；可通过 replace+provide 虚拟包别名或封装隔离实现兼容；常见做法是用 conflict 和 provide 声明 v8 兼容 v7 接口契约。
Composer 无法直接安装 Guzzle 多个主版本共存
Composer 的依赖解析器不允许同一包（如 guzzlehttp/guzzle）在根项目中同时存在多个主版本（例如 v7 和 v8）。这不是限制，而是设计使然：每个包名对应唯一 autoloader 命名空间（GuzzleHttp\），类名冲突无法绕过。所谓“多版本共存”，实际只能通过以下两种路径之一实现：
- 用
replace+provide配合虚拟包（virtual package）做版本别名映射，让不同组件“以为”自己在用不同版本； - 将某版本封装进独立的 Composer 插件或私有包，用
autoload-dev或运行时加载隔离命名空间（不推荐，维护成本高）。
用 conflict 和 provide 模拟 Guzzle v7 别名
常见场景：你依赖的 A 包硬要求 guzzlehttp/guzzle:^7.0，B 包硬要求 ^8.0，而你当前项目已装 v8。此时可手动告诉 Composer：“v8 兼容 v7 的接口契约”，方法是在 composer.json 根节点添加：
"conflict": {
"guzzlehttp/guzzle": "<8.0"
},
"provide": {
"guzzlehttp/guzzle": "7.4.5 as 7.99.99"
}
说明：
-
conflict阻止旧版 Guzzle 被意外引入； -
provide声明当前项目“提供”一个虚拟的guzzlehttp/guzzle版本7.99.99，它由真实 v8.4.5 “扮演”； - 版本号写成
X.YY.ZZ as X.AA.BB是 Composer 别名语法，as左边是真实版本，右边是对外宣称的兼容版本； - 该方式仅对依赖声明生效，不改变实际代码行为——你要确保 v8 确实向后兼容 v7 的公共 API（Guzzle 官方承诺 v8 兼容 v7 的客户端接口，但废弃了
Stream等内部类）。
为什么不能用 require 同时写两个 Guzzle 版本
执行 composer require guzzlehttp/guzzle:^7.0 guzzlehttp/guzzle:^8.0 会直接报错：
[InvalidArgumentException] Package guzzlehttp/guzzle cannot be found in the repository
原因很直接：
- Composer 解析时发现同一个包名出现两次，立即终止；
- 即使手动编辑
composer.json强行写两行require，运行composer update也会触发冲突检测并失败； - 更隐蔽的坑：某些私有仓库或 fork 试图用不同 vendor 名（如
myorg/guzzle7）重发布 Guzzle，但一旦和官方包共存，PSR-4 自动加载仍会因GuzzleHttp\命名空间重叠导致类覆盖或Class not found错误。
真正需要多版本隔离时，只有一种可靠方案
如果你必须在同一个 PHP 进程里调用 Guzzle v7 和 v8 的**不同实例**（比如对接两个 API，一个只认 v7 的中间件，一个强制要 v8 的异步特性），那就不能靠 Composer 别名，得用运行时隔离：
- 把其中一个版本放进子进程（
proc_open+ 单独 CLI 脚本），用 JSON 通信； - 或改用
include方式加载某个版本的vendor/autoload.php到独立作用域（需配合ClassLoader::addPsr4()手动注册，且不能与主 autoloader 冲突）； - 最稳妥的是拆服务：v7 逻辑走一个微服务，v8 走另一个，HTTP 通信——这反而比强行共存更易测试、部署和 debug。
别名只是让 Composer “闭嘴”，不是让 PHP “分身”。真要双版本，就得接受边界成本。
