Composer无法解决类名重复冲突，因其仅负责文件加载而非运行时类管理；PHP禁止同名类重复声明，需通过replace/conflict声明互斥或重构为接口+DI解耦。
Composer 依赖中类名重复时，autoload 无法解决冲突
Composer 本身不处理运行时类名冲突——它只负责把类文件按 autoload 规则载入。一旦两个不同包里定义了同名的 class（比如都叫 Helper），PHP 在 require 时会直接报 Fatal error: Cannot declare class Helper。这不是 Composer 的 autoload 配置能绕过的，因为 PHP 的类加载机制不允许重复声明。
用 classmap + 命名空间重映射可临时规避（但不推荐）
某些老项目或私有包中，若你完全控制源码，可手动修改冲突包的类文件，加命名空间，并在 composer.json 中用 classmap 指向新路径。但这破坏了包的原始结构，升级时极易出错。
- 必须确保所有引用该类的地方同步改用新命名空间
-
classmap不支持自动发现子命名空间，需显式列出每个类文件 - Composer 官方明确不鼓励用
classmap覆盖第三方包的 autoload
{
"autoload": {
"classmap": ["vendor/conflict-pkg/src/MyHelper.php"]
}
}
真正可行的方案：用 replace 或 conflict 显式声明互斥
当两个包提供功能重叠且类名冲突（如 monolog/monolog 和某个自研日志类库也叫 Logger），应在你的项目 composer.json 中用 replace 声明“我已提供替代实现”，或用 conflict 阻止同时安装。
-
"replace": {"conflict-pkg/name": "*"}表示你自行实现了该包全部接口，Composer 就不会再去装它 -
"conflict": {"other-pkg/name": ">=2.0"}可阻止特定版本共存，避免加载冲突类 - 注意：
replace不会自动重命名类，只是让 Composer 跳过安装被替换的包
别名（alias）只适用于版本别名，不是类名别名
Composer 的 alias 是对包版本的虚拟标签（如 "dev-main as 2.0.x-dev"），它影响的是版本解析和依赖约束匹配，**完全不涉及运行时类名、命名空间或文件加载路径**。网上所谓“用 alias 给类起别名”是常见误解，PHP 层面没有这种机制。
- 类名别名只能靠 PHP 的
class_alias()函数在运行时做（但极不安全，易引发反射失败、IDE 无法识别等问题） - Composer 的
autoload > psr-4或psr-0映射的是命名空间到路径，不是类名到类名 - 试图用 Composer 配置解决类名冲突，本质是方向错了——该由包作者用唯一命名空间隔离，或由你用依赖倒置解耦
最常被忽略的一点：类名冲突往往暴露的是架构问题——过度依赖全局类名、未遵循 PSR-4 命名规范、或强行复用非标准包。比起找“别名技巧”，优先检查是否该用接口抽象 + DI 容器来解耦调用方与具体实现。
