Composer不支持多个包声明相同命名空间，会覆盖autoload映射导致Class not found；唯一可行方案是改用classmap并手动维护，确保类文件路径不重名且每次新增类后运行composer dump-autoload。
Composer 加载多个包同命名空间时，会直接报错
Composer 不支持两个不同包声明完全相同的命名空间（比如都用 AppServices），它在生成 autoload_psr4.php 时只会保留最后一个注册的映射，前面的被覆盖。运行时一旦调用被覆盖路径下的类，就会抛出 Class not found —— 而且错误信息里根本不会提示“有冲突”，只说找不到。
唯一可行方案：强制让 Composer 把所有同名空间映射都收进来
靠修改 composer.json 的 psr-4 配置本身做不到这点，必须改用 classmap + 手动维护 autoload 映射。这不是“推荐做法”，而是目前唯一能绕过 Composer 内部覆盖逻辑的方式：
- 在每个包的
composer.json中，删掉psr-4对该命名空间的声明，改用"classmap": ["src/"] - 主项目执行
composer dump-autoload -o，确保 classmap 生效 - 所有同名空间下的类，必须保证文件路径不重名（例如
PackageA/src/CacheService.php和PackageB/src/CacheService.php不能同时存在）
注意：classmap 不支持自动发现新增类，每次加新类都要重新运行 composer dump-autoload。
为什么不用符号链接或自定义 autoloader？
有人试过用 symlink 把多个包的 src 合并进一个目录，再统一 psr-4 注册——这在开发机可能跑通，但上线后因部署工具（如 Capistrano、Envoyer）清空 vendor 或使用 artifact 部署，符号链接极易断裂；而手写 spl_autoload_register 则会绕过 Composer 的优化（如 APCu 缓存），且和 composer install --no-dev 等行为不兼容。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Composer 的 autoload 机制是单入口、不可插拔的，没法“叠加”多个 psr-4 映射
- 哪怕你用
autoload-dev分开注册，最终生成的autoload_static.php仍是扁平覆盖结构 - PHP 8.2+ 的
#[Override]和命名空间无关，对 autoload 冲突毫无帮助
真正要检查的不是命名空间，是类名是否全局唯一
很多人卡在“为什么两个包用了同样 namespace 却不报错”，其实是因为它们没引入同名类。只要 use AppServicesCacheService; 在两个包中指向不同文件，而你在项目里只用了其中一个，就暂时相安无事。但一旦某天引入了第二个包里的同名类，或者升级后某个包内部重构导致类名碰撞，问题立刻暴露。
- 用
composer show --tree查看依赖树，手动检查各包的autoload.psr-4值 - 用
grep -r "namespace App\\Services" vendor/快速定位哪些包在声明这个空间 - CI 中可加脚本校验：解析所有
composer.json的autoload.psr-4，检测重复键值
命名空间冲突不是配置问题，是包设计层面的耦合信号。真遇到多包强依赖同一命名空间，得回头问一句：它们本该是一个包吗？
