根本原因是多个包或本地代码存在同名命名空间+类名，导致autoload_psr4.php或autoload_classmap.php写入重复键，后注册覆盖先注册；需用composer dump-autoload -o后检查这两个文件中对应命名空间或类名是否多处出现。

为什么 composer dump-autoload 生成的类文件名会冲突？

根本原因是 Composer 的自动加载机制依赖文件路径与命名空间/类名的严格映射，当多个包或本地代码中存在同名命名空间+类名（哪怕文件路径不同），autoload_psr4.php 或 autoload_classmap.php 就可能写入重复键，导致后注册的类覆盖先注册的——运行时实际加载的是最后一个被写入的版本。

• 常见于开发中手动创建了与 vendor 包同名的类（如都叫 AppServicesLogger）
• 两个第三方包声明了完全相同的 PSR-4 前缀（例如都用 "Acme\": "src/"）
• 使用 classmap 方式时，多个目录下存在同名 .php 文件（如都叫 Helper.php），且未加命名空间隔离

怎么快速定位冲突的类名？

别翻源码，直接看生成的 autoload 文件本身。执行 composer dump-autoload -o 后，打开 vendor/composer/autoload_psr4.php，搜索你怀疑冲突的命名空间前缀（比如 "App"），观察是否对应多个路径；再打开 vendor/composer/autoload_classmap.php，用 Ctrl+F 搜具体类名（如 "AppServicesLogger"），如果搜到不止一处，就是冲突点。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 注意：仅 -o（optimize）模式会生成 autoload_classmap.php，普通模式只生成 PSR-4/PSR-0 映射
• 若用 composer install --no-dev，记得在对应环境下重新 dump，dev 和 prod 的 autoload 可能不同
• 某些 IDE 插件（如 PHPStorm 的 Composer Support）会高亮显示“无法解析的类”，这往往是冲突的第一信号

如何避免 PSR-4 映射层面的命名冲突？

核心原则：命名空间前缀必须全局唯一，不能靠“我本地不用那个包”来侥幸。Composer 不做运行时校验，只按 composer.json 里写的顺序合并映射，后加载的赢。

• 项目主命名空间建议用公司/组织域名反转形式，如 "mycompany\": "src/"，而非宽泛的 "App\"
• 第三方包若声明了过于通用的前缀（如 "Support\"），优先通过 replace 或 conflict 在 composer.json 中显式声明不兼容
• 临时调试时可删掉 vendor/composer/autoload_*.php，再运行 composer dump-autoload -vvv，它会打印每条映射的来源（哪个包、哪个 composer.json）

autoload-dev 和生产环境冲突怎么办？

开发专用类（如测试工具、Mock 类）如果也用了和生产代码一样的命名空间，autoload-dev 里的映射会在 dev 环境下覆盖生产映射，但上线后又消失——造成行为不一致。这不是 bug，是设计如此。

• 解决方案：dev 类必须使用独立命名空间，例如 "MyApp\Tests\": "tests/"，绝不和 "MyApp\" 混用
• 检查 composer.json 中 autoload 和 autoload-dev 是否有重叠路径（如都包含 "src/"）
• CI 环境跑测试前务必执行 composer install --no-dev，否则可能误用 dev 下的类掩盖真实问题

实际项目里最常被忽略的是：冲突不一定报错，而是静默加载错误版本的类——比如你改了 src/Service/Api.php，却一直走着 vendor 里同名类的逻辑。盯住 vendor/composer/autoload_*.php 里的键值对，比猜更可靠。