composer仅以name字段为包唯一标识，同名即安装失败；psr-4命名空间映射后加载者覆盖前者，导致class not found；类名冲突无法通过autoload或alias解决，必须改命名空间或用代理类。
Composer 不会帮你解决包名或命名空间冲突，它只认 name 字段为唯一标识，同名即报错；类名冲突更不是 autoload 能绕过的——PHP 运行时直接 Fatal error: Cannot declare class。
为什么改了 composer.json 的 psr-4 还是加载失败
Composer 的 psr-4 映射是“覆盖式注册”：多个包若声明相同命名空间前缀（如都写 "App\": "src/"），后加载的会完全覆盖前一个，导致部分类路径丢失。运行时调用被覆盖路径下的类，就报 Class not found，且错误信息里根本不提“有冲突”。
- 检查所有依赖包的
composer.json，用grep -r '"psr-4"' vendor/找出谁在宽泛映射 - 特别警惕
""（空字符串）作为命名空间前缀的写法，它等于把整个src/目录平铺进全局空间 -
composer dump-autoload -o后生成的vendor/composer/autoload_psr4.php是最终映射表，可直接打开看哪条被留了下来
同名包（name 字段重复）安装直接中止
错误提示一定是 Package xxx is already registered，这不是 autoload 阶段问题，而是依赖解析器在内存注册时就拒绝第二个同名包——根本不会走到文件加载。
- 运行
composer validate --strict，它会明确指出composer.json中重复的name声明 - 检查
repositories数组，尤其是type: "package"条目，里面"name"必须和require中完全一致，否则会被当成另一个包重复注册 - fork 包必须改
name，例如从"monolog/monolog"改成"acme/monolog"；只改 URL 或分支没用
类名冲突不能靠 alias 或 autoload 配置解决
网上说的 “Composer 别名给类起别名” 是典型误解。alias 只用于 repositories 中的 package 类型，且仅影响版本解析（如 "dev-main as 2.0.0"），跟类名、命名空间、文件路径毫无关系。
-
class_alias()虽然能在运行时重命名类，但会导致反射失败、IDE 无法跳转、类型提示丢失，生产环境禁用 -
replace和conflict只作用于安装阶段：前者让 Composer 跳过装某个包，后者阻止共存，但都不影响已加载类的命名空间 - 真正安全的解法只有两个：改源码加唯一命名空间（需你有权限），或写代理类封装（不碰原包，用
new VendorACache()包一层）
临时屏蔽冲突类的唯一有效方式
当上游包没法改、又必须集成时，exclude-from-classmap 是唯一能精准“止血”的配置项，但它只对 classmap 生效，对 psr-4 无效。
- 先确认冲突包用的是
classmapautoload：查它的composer.json，看是否有"classmap": ["src/"] - 在你项目的
composer.json中添加："exclude-from-classmap": ["vendor/bad/pkg/src/Helper.php"] - 执行
composer dump-autoload -o，然后手动require或写代理类来替代被屏蔽的类
最常被忽略的一点：你以为改了 name 或加了 replace 就万事大吉，结果运行时报 Class not found——那是因为 autoload 路径没同步更新，而这个环节和包名冲突完全独立，却极少被检查。
