因为php不支持同命名空间多版本共存，composer autoloader为单例设计，仅注册一次guzzlehttp\映射，后加载版本会覆盖前者；依赖解析时composer强制取交集版本，v6与v7无共同满足约束的版本，直接报conflict退出。

为什么不能直接在同一个 vendor 里装两个版本的 Guzzle？

Composer 的 autoloader 是单例设计，vendor/autoload.php 只会注册一次 PSR-4/PSR-0 映射，后加载的同名命名空间会覆盖前一个。比如你硬塞进 guzzlehttp/guzzle v6 和 v7，它们都声明了 GuzzleHttp\ 根命名空间，运行时只会生效其中一个——具体哪个，取决于 composer dump-autoload 的扫描顺序，不可控。

更麻烦的是，依赖树会塌缩：如果 A 包 require guzzle:^6.5，B 包 require guzzle:^7.4，Composer 解析时会尝试找一个同时满足两者的版本（不存在），直接报 conflict 并退出。它不会给你“并存”的选项。

所以别试图用 composer require 往同一项目里硬加多版本——这不是功能缺失，是设计使然。

用独立 vendor 目录 + 手动 require 实现运行时隔离

当两个版本只在完全隔离的上下文中使用（例如 CLI 命令调用旧版 SDK，Web 请求走新版 HTTP 客户端），可以放弃 Composer 统一 autoloader，改用 require_once 显式加载特定版本的 autoload 文件。

• 把不同版本分别安装到互不重叠的目录，比如 vendor-guzzle6/ 和 vendor-guzzle7/
• 各自执行 composer install，确保 vendor-guzzle6/autoload.php 和 vendor-guzzle7/autoload.php 都存在
• 在需要的地方手动加载：require_once __DIR__.'/vendor-guzzle6/autoload.php';
• 注意：必须确保两个 autoload 文件不被同时引入，否则类重复定义会 fatal error

这种做法绕过了 Composer 的依赖解析，但也意味着你得自己管理冲突——比如两个 vendor 目录里都装了 psr/http-message，但版本不同，而你的代码又直接用了它的接口，就可能出问题。

config.platform 不是用来“切换版本”的，而是防止误装

config.platform 只影响 composer install 或 update 时的依赖解析逻辑，它不会改变已安装包的行为，也不会让两个版本共存。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

它的真正用途是：当你本地 PHP 版本或扩展比目标环境高时，避免 Composer 装上那些“本地能跑、线上崩掉”的包。

• 例如线上是 PHP 8.1，你本地是 PHP 8.3，就在 composer.json 里写："php": "8.1.0"（必须是具体值，^8.1 无效）
• 它不会阻止你装 guzzlehttp/guzzle:^7.4，但会拒绝装仅兼容 PHP 8.2+ 的某个子依赖
• 如果你真想在一台机器上跑 Laravel 7 和 Laravel 8 项目，config.platform 帮不上忙——那是项目级隔离，不是包级

别把它当成“虚拟环境开关”，它只是个解析期的守门员，不是运行时的调度器。

Docker Compose 是更干净的多版本共存方案

比起在宿主机上折腾多个 vendor、手动 require、平台配置，用 Docker Compose 为每个项目起独立容器，才是面向生产的真实解法。

每个服务可定义自己的 PHP 版本、扩展、甚至 Composer 版本：

• 用 image: php:8.1-apache 跑 Laravel 7，image: php:8.3-cli 跑 Laravel 8 的命令行工具
• 每个容器的 /app 挂载对应项目的代码，vendor 完全隔离，无共享风险
• 端口、网络、环境变量全部通过 docker-compose.yml 控制，不会出现 Address already in use

复杂点在于调试链路变长——比如要进容器看日志、查进程、连 Xdebug，但换来的是确定性。本地开发机上混装七八个 PHP 版本和几十个 vendor 目录，迟早遇到 Class 'GuzzleHttp\Client' not found 却查不出是哪个 autoload 搞的鬼。