Composer不支持同一包多版本共存，因自动加载机制要求类名唯一。1. 命名空间无法天然隔离同包不同版本；2. 推荐方案为依赖隔离，如拆分为独立服务；3. 高级方案可用php-scoper重写类前缀实现作用域隔离；4. 优先考虑升级依赖或替换组件；5. 运行时包含仅限简单场景，生产环境慎用。合理架构优于强行合并。
在PHP项目中，你可能会遇到一个棘手的问题：需要同时使用同一个Composer包的不同版本。比如，你的项目依赖某个库的v2版本，而另一个第三方组件却要求该库的v1版本。很遗憾，Composer本身不支持在一个项目中加载同一个包的多个版本。这与PHP的命名空间机制和Composer的自动加载设计有关。
为什么不能直接使用多个版本？
Composer通过PSR-4或PSR-0规范将类名映射到文件路径，并生成统一的自动加载文件（如vendor/autoload.php）。每个类名必须唯一对应一个文件。如果两个版本的同一个包都定义了相同的命名空间和类名（例如Vendor\Package\ClassName），PHP无法区分它们，会导致类覆盖或致命错误。
换句话说：
- Composer安装时会锁定每个包的唯一版本。
- 自动加载器只注册一次类名到文件的映射。
- 即使你手动修改autoload配置，也无法让PHP同时加载两个同名类。
常见误区：命名空间可以隔离不同版本？
有些人认为可以通过重命名命名空间来实现隔离。但默认情况下，包的源码中的命名空间是固定的。例如，monolog/monolog始终使用Monolog\开头的命名空间。除非你对源码进行修改，否则无法靠命名空间天然隔离。
立即学习“PHP免费学习笔记（深入）”；
也就是说，原生的命名空间机制并不能解决多版本共存问题，它只是组织代码的结构工具，不是运行时隔离手段。
可行的解决方案
虽然不能直接共存，但有几种策略可以绕过这个限制：
方案一：使用依赖隔离（推荐）
将需要旧版本包的功能封装成独立的子项目或微服务，通过API、命令行调用或消息队列与其通信。这样主项目和子项目各自维护自己的composer.json，互不影响。
例如：
- 主项目使用package/v2。
- 另起一个小型HTTP服务，使用package/v1处理特定任务。
- 主项目通过Guzzle等客户端调用该服务。
优点：彻底隔离，安全可靠。缺点：增加运维复杂度。
方案二：类名前缀重写（高级技巧）
使用工具如php-scoper对其中一个版本的包进行“作用域隔离”。它会扫描代码，将类、函数、常量加上自定义前缀，并重写命名空间。
操作步骤：
- 创建一个单独目录，安装所需的老版本包。
- 运行php-scoper，生成带前缀的隔离版本（如ScopedV1\Monolog\Logger）。
- 将生成的代码复制到项目中，并通过额外的autoloader加载。
注意：需处理闭包、序列化、动态调用等边界情况。适合技术能力强的团队。
方案三：寻找替代包或升级依赖
检查是否可以替换掉强制依赖老版本的组件。或者联系其维护者推动升级。有时社区已有兼容新版本的分支或替代实现。
也可以尝试fork并自行升级依赖，虽然增加了维护成本，但能从根本上解决问题。
方案四：运行时包含+命名空间别名（有限适用）
对于极少数不依赖自动加载、仅包含函数或可手动include的场景，可通过隔离目录+require_once+命名空间别名临时应对。
例如：
require_once 'legacy-vendor/autoload.php'; // 使用前面加别名的方式调用 use LegacyPackage as OldPackage;
但这种方式容易冲突，不推荐用于生产环境。
基本上就这些。Composer的设计决定了它不适合多版本共存，关键在于合理架构项目边界。隔离比强行合并更可靠。
