Composer alias 并非官方功能，也不能解决包冲突；它只是安装时的版本映射标记（如 "as"），无法实现同一包多版本共存，因 vendor 目录扁平且类加载无隔离机制。
什么是 composer alias？它其实不能解决包冲突
直接说结论：composer alias 并不是 Composer 官方支持的功能，也**不能用于让不同版本的同一包共存**。你看到的所谓“alias”通常是指 composer.json 中的 "replace"、"provide" 字段，或是通过 repositories + package 类型手动定义包时写的 "as" 别名（如 "monolog/monolog": "dev-main as 2.10.0"），但这个 as **只是安装时的版本映射标记，不是运行时别名机制**。
PHP 不支持命名空间级或类级的“包别名”，Composer 的依赖解析器只认 vendor/autoload.php 加载的类名和 PSR-4 映射——一旦两个包提供完全相同的命名空间和类名（比如都定义了 IlluminateSupportStr），就会发生致命冲突，composer install 甚至可能直接失败。
为什么 "as" 不能让 v1 和 v2 同时加载？
"as" 只在 composer install 阶段起作用：它告诉 Composer “把这个源码分支当作某个稳定版本来满足依赖”。例如：
{
"repositories": [
{
"type": "package",
"package": {
"name": "myorg/http-client",
"version": "dev-legacy",
"source": {
"url": "https://git.example.com/myorg/http-client-legacy.git",
"type": "git",
"reference": "v1.2"
},
"autoload": { "psr-4": { "MyOrg\HttpClient\": "src/" } },
"as": "1.2.0"
}
}
],
"require": {
"myorg/http-client": "^1.2"
}
}
这只能让你「用一个私有旧版代码满足对 1.2.0 的依赖」，但如果你同时 require "myorg/http-client": "^2.0"，Composer 会拒绝安装——因为同一个包名不能有两个不兼容的主版本共存于 vendor/。
- Composer 的
vendor/是扁平结构，每个包名只保留一份物理目录 -
as不改变自动加载路径，也不隔离类加载器 - 即使你 hack 出两份代码放不同目录，PSR-4 映射冲突或
class_exists()检查仍会出问题
真正可行的共存方案：改名 + 自动加载隔离
若必须让两个不兼容版本（如 guzzlehttp/guzzle 6 和 7）在同一项目中使用，唯一可靠方式是：**手动重命名其中一个包，并修改其所有命名空间与类引用**。这不是 Composer 能自动做的，需要你介入代码层：
- 用
git clone拉取旧版源码，把src/下所有GuzzleHttp替换为GuzzleHttpV6 - 更新
composer.json的autoload，指向新命名空间 - 在调用处显式 use
GuzzleHttpV6Client，而非GuzzleHttpClient - 避免使用
class_alias()做运行时映射——它无法解决 trait、interface 或静态方法签名差异
注意：这种方案维护成本高，仅建议用于遗留集成桥接场景。现代项目应优先升级依赖，或用 API 封装/适配器模式隔离外部 SDK 版本差异。
替代思路：进程隔离或微服务化
如果两个版本的逻辑完全独立（比如一个模块用 Guzzle 6 调老接口，另一个用 Guzzle 7 调新接口），更健壮的做法是：
- 将旧版逻辑抽成独立 CLI 命令或 HTTP 微服务，用
proc_open()或 cURL 调用 - 用 Docker 分别运行不同 PHP 环境（含对应 Guzzle 版本），通过 HTTP 通信
- 避免在单个 PHP 进程内硬扛多版本冲突
别名不是银弹。Composer 的设计哲学是“确定性依赖”，强行绕过版本约束只会把问题推迟到运行时——而那时堆栈里连哪行 new Client() 触发了冲突都难定位。
