Composer 不支持同一包多版本共存，因其依赖图必须是单向无环，且 PHP autoloader 无版本隔离机制；可行方案包括重命名包、接口抽象、适配器封装或运行时手动加载。
Composer 本身不支持在一个项目中同时安装同一包的两个不同版本——composer install 最终只会保留一个满足所有约束的解析结果，冲突时会报错 Root composer.json requires xxx ^1.0 and xxx ^2.0 -> satisfiable by xxx[1.x] and xxx[2.x]。这不是配置疏漏，而是依赖图必须是单向无环的硬性限制。
为什么不能直接 require 同一包的两个版本
Composer 的依赖解析器（composer/semver + composer/dependency-resolver）在构建依赖图时，对每个包名只允许一个已安装的版本实例。即使你手动修改 composer.json 写入两个冲突的 require 条目，composer update 也会失败并提示无法解决的约束冲突。
- PHP 的 autoloader（如 Composer 的
ClassLoader）按命名空间或类名映射到文件路径，不支持“按版本加载不同实现” - 没有类似 Java 的 ClassLoader 隔离机制，也无法像 Node.js 的
node_modules嵌套结构那样让子依赖各自携带副本 -
replace、provide或conflict字段只能声明排他关系，不能启用多版本共存
实际可行的规避方案：用替代包名或封装层隔离
核心思路是让两个版本“看起来不是同一个包”。这需要上游包配合（如提供别名），或你主动封装一层抽象。
- 如果目标包支持官方别名（如
monolog/monolog提供psr/log接口），优先依赖抽象接口而非具体实现 - 若需同时用
guzzlehttp/guzzle6.x 和 7.x，可 fork 其中一个版本，重命名name字段（如改为mycompany/guzzle6-bridge），再通过repositories引入本地或私有源 - 对关键类做适配器封装：写一个
LegacyClient类，内部用require_once加载 v1 版本的独立 autoloader（需确保其不与主 autoloader 冲突），仅暴露你需要的方法
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/yourname/guzzle6-bridge"
}
],
"require": {
"guzzlehttp/guzzle": "^7.5",
"mycompany/guzzle6-bridge": "^6.5"
}
}
运行时动态加载：适用于明确分离使用场景
当两个版本只在完全隔离的上下文中使用（如 CLI 命令 vs Web 请求），可放弃 Composer 统一管理，改用 include 或 require_once 手动加载特定版本的 autoload.php。
- 确保两个版本的 vendor 目录不重叠（例如分别放在
vendor-guzzle6/和vendor-guzzle7/） - 在调用前清空
ClassLoader::$prefixesPsr4等静态状态（风险高，慎用）或使用include替代自动加载 - 必须禁用 opcache 的
opcache.enable_cli=1（CLI 场景），否则可能缓存错误的类定义
// 在某个命令中单独加载 v6 require_once __DIR__ . '/vendor-guzzle6/autoload.php'; $client = new \GuzzleHttp\Client(['base_uri' => 'https://legacy.api/']);
真正难的不是技术上绕开 Composer，而是维护成本：fork 包要同步安全更新，手动加载要自己处理类冲突和 autoloader 干扰。多数情况下，应优先推动依赖方升级，或用 Adapter 模式收敛到单一版本。
