Composer要求同一包仅能安装一个版本，因其扁平依赖树和自动加载机制会导致类名冲突。无法共存时可通过服务拆分、适配器模式、替换声明或插件化架构实现隔离，优先推荐解耦设计以避免维护问题。
在使用 Composer 管理 PHP 项目依赖时，一个核心原则是：同一个包的同一个名称，在一个项目中只能安装一个版本。这意味着 不能直接在一个项目中并存多个不同版本的同一依赖包。比如你无法同时安装 monolog/monolog 的 1.x 和 2.x 版本。
为什么不能并存多个版本？
Composer 构建的是一个扁平的依赖树，所有类都通过自动加载机制注册到同一个命名空间下。如果两个版本的同一个包被加载，PHP 无法区分同名类，会导致冲突或不可预知的行为。因此 Composer 在解析依赖时会尝试找到一个满足所有依赖要求的“统一版本”。
替代方案：解决多版本需求的实际方法
虽然不能直接共存，但可以通过以下方式应对需要多个版本的场景：
隔离环境将需要不同依赖版本的功能拆分为独立的项目或服务：
- 例如，把使用旧版 SDK 的模块做成一个微服务，新版功能在另一个服务中实现
- 通过 API 或消息队列进行通信，避免共享代码库中的版本冲突
统一使用一个版本，但通过抽象层兼容不同行为：
- 定义通用接口，为不同版本的包编写适配器
- 运行时根据配置选择具体实现，对外提供一致调用方式
- 这样即使底层依赖版本不同，上层代码仍可灵活切换
Composer 提供了 replace 和 provide 功能，可用于虚拟替换包，但这不是真正意义上的多版本共存：
- 可以声明某个包“代替”另一个包，避免冲突
- 适用于 fork 后自行维护的版本，或互为兼容的实现
- 不能用于同时加载原始包和替换包
对于复杂系统，可设计插件机制，延迟加载特定版本的依赖：
- 主程序不直接依赖具体版本，插件各自声明所需依赖
- 通过独立的 Composer 安装目录管理插件依赖
- 利用命名空间隔离或 PHAR 打包避免类冲突
总结
Composer 不支持在同一项目中安装同一包的多个版本。遇到此类需求时，应优先考虑架构层面的解耦，如拆分服务、引入适配层或插件机制。强行绕过 Composer 的版本约束往往带来维护难题。合理规划依赖关系，保持项目结构清晰，才是长期可控的解决方案。
