Composer无法在同一项目中安装同一包的多个版本，这是由PHP自动加载机制和Composer依赖图DAG模型共同决定的硬限制；唯一可行方案是通过fork并修改name字段实现物理隔离。
Composer 无法在一个项目中同时安装同一包的多个版本——这不是配置没写对，是 PHP 自动加载机制和 Composer 依赖图模型共同决定的硬限制。
为什么 composer require "foo/bar:^1.0" "foo/bar:^2.0" 必然失败
Composer 的依赖解析器（composer/dependency-resolver）要求整个依赖树是单向无环图（DAG），每个包名只能对应一个解析出的版本。报错信息类似：
Root composer.json requires foo/bar ^1.0 and foo/bar ^2.0 -> satisfiable by foo/bar[1.x] and foo/bar[2.x]
这不是“没配好”，而是它明确拒绝构造逻辑矛盾的依赖关系。PHP 的 ClassLoader 按类名映射到文件路径，不感知版本；vendor 目录下 foo/bar 只能有一个实际解压目录，不可能并存 v1 和 v2 的源码。
- 手动在
composer.json里写两行同名包的require，composer update会直接中断 -
replace、provide、conflict字段只能声明排他或兼容性，不能启用多版本共存 -
autoload-dev中的映射不会自动隔离——生产环境仍可能因硬引用触发 Class not found
用 name 重命名 + repositories 是唯一让 Composer “认作不同包”的方式
如果你控制该包源码，或愿意 fork 维护一个变体，这是最干净的物理隔离方案：
- fork
foo/bar，修改其composer.json中的name字段（如改为mycompany/foo-bar-legacy） - 同步更新所有命名空间（如从
Foo\Bar改为MyCompany\FooBarLegacy） - 在主项目中通过
repositories引入（类型path或vcs），再require "mycompany/foo-bar-legacy": "^1.5" - 确保新旧两个包的 autoload 配置互不重叠，避免 PSR-4 映射冲突
注意：repositories 不解决自动加载冲突——必须靠命名空间隔离，否则 dump-autoload 仍会覆盖或报错。
运行时手动加载（require_once + 独立 autoloader）只适用于极简场景
当 v1 和 v2 仅需调用少量函数、且不依赖对方生态时，可临时绕过 Composer 加载：
- 把 v1 的完整包（含其
vendor/和autoload.php）单独放在项目外目录（如legacy-sdk/） - 在业务代码中用
require_once 'legacy-sdk/vendor/autoload.php';启动独立加载器 - 用闭包或独立作用域封装调用，避免污染全局
ClassLoader - 严禁让 v1 的类被主项目的
autoload.php扫描到（检查 PSR-4 映射路径）
风险明显：v1 若依赖 monolog/monolog，你得手动保证它自己的 vendor/ 也存在且版本匹配——这本质上退化成手动维护 mini vendor，不可测试、不可部署。
config.platform.php 对包版本完全无效，别试
config.platform 只模拟 PHP 版本或扩展是否存在，**不支持任何包名级别的模拟**。以下配置毫无作用：
"config": { "platform": { "foo/bar": "1.5.0" } }
Composer 会静默忽略该字段，既不报错也不生效。很多用户误以为它能“降级锁定某个包”，结果发现 composer.lock 里还是 v2，或者 v1 的类根本加载不到——因为平台配置根本不参与包版本选择逻辑，只影响 ext-* 和 php 约束校验。
真正容易被忽略的是：即使你用重命名+适配器方案，只要两个版本共享了同一个第三方依赖（比如都用 psr/http-client），而它们要求的版本范围又不兼容，Composer 仍会在顶层报冲突——这时你得靠 conflict 或升级其中一方来收口，而不是继续加 wrapper。
