Composer自动加载路径重复会导致类找不到或加载错版本，因多个包映射相同命名空间到不同路径；classmap和psr-4混用时后注册的映射会覆盖前者，且classmap不检查冲突，psr-4冲突更隐蔽；需用composer dump-autoload -vvv定位覆盖源，优先修改依赖包autoload配置并执行dump-autoload生效。
Composer 自动加载路径重复不会直接报错，但会导致类找不到或加载错版本——问题不在 autoload 块本身，而在多个包映射了相同命名空间到不同物理路径。
为什么 classmap 和 psr-4 混用会悄悄覆盖类
Composer 的 autoloader 是“先注册、后合并”，不是“去重合并”。如果两个包都声明了 "psr-4": {"App\": "src/"}，后加载的那个会覆盖前一个的路径映射，运行时就可能从错误目录加载类。
-
classmap条目是扁平扫描，不检查命名空间冲突；若两个classmap都包含Helper.php，最终只保留最后一次扫描到的定义 -
psr-4映射冲突更隐蔽：A 包写"MyLib\": "lib/"，B 包也写"MyLib\": "vendor/myorg/mylib/src/"，后者生效，前者类永远无法被自动加载 - 运行
composer dump-autoload -v会输出类似Warning: Ambiguous class resolution for "MyLibFoo"的提示（但默认不显示，需加-v）
如何定位哪个包在偷偷覆盖命名空间
别靠肉眼搜 composer.json，用 Composer 自带命令快速揪出源头：
- 执行
composer show --platform确认当前已加载的 autoload 规则（含 vendor 和本地包） - 运行
composer dump-autoload -vvv | grep -A5 -B5 "MyLib\"（把MyLib\替成你的目标命名空间），看哪条映射最后出现 - 查具体包：用
composer show vendor/package-name查它的autoload字段；再用grep -r '"MyLib\\":' vendor/*/composer.json扫描所有已安装包
psr-4 路径重复时必须改哪边
优先改 fork 包或私有包的 autoload，而不是主项目。因为主项目的 autoload 只影响自身代码，而依赖包的映射会注入全局 autoloader。
- 若 fork 包原本是
"Monolog\": "src/"，但你改了命名空间为MyOrgMonolog，就必须同步改成"MyOrg\Monolog\": "src/"，不能留着旧映射 - 不要在主项目
autoload里强行加一条"Monolog\": "vendor/myorg/monolog/src/"来“覆盖”——这会破坏 PSR-4 规范，且下次dump-autoload可能被清掉 - 改完后必须运行
composer dump-autoload，否则新映射不生效；如果用了optimize-autoloader，还得加--optimize参数重新生成 classmap
classmap 冲突比 psr-4 更难察觉
classmap 不走命名空间路由，只靠文件名匹配。两个包都跑过 composer dump-autoload 生成 classmap，就可能出现同名类指向不同路径。
- 现象：调用
new Helper()却加载了旧版Helper，而你确定改了源码——大概率是另一个包的 classmap 缓存了旧文件 - 验证方法：删掉
vendor/composer/autoload_classmap.php，再执行composer dump-autoload --no-dev，观察生成的新文件里Helper指向哪条路径 - 根治办法：fork 包禁用 classmap，改用
psr-4；主项目若必须用 classmap，确保只对自身src/目录生成，避免扫进vendor/
最容易被忽略的是：autoload 修改后没清掉 OPCache 或 Composer 的脚本缓存。哪怕 autoload_classmap.php 已更新，PHP 还可能从 OPCache 里读旧映射。遇到“明明改了却没生效”，先试 php -r "opcache_reset();" 和 composer clear-cache。
