Composer加载同名类时会直接报Fatal error，因autoload无优先级机制；应通过PSR-4严格隔离命名空间、检查并修正冲突包的autoload配置，必要时用exclude-from-classmap临时屏蔽。
Composer 加载同名类时到底发生了什么
Composer 不会自动解决类名冲突，它只按 autoload 规则把 PHP 文件映射到类名，一旦两个包都声明了 App\Helper 这种类，且都被加载进同一运行环境，PHP 就会在第二次 class_exists 或实例化时直接报 Fatal error: Cannot declare class AppHelper —— 没有警告，不给你机会，直接崩。
用 PSR-4 映射隔离命名空间是最可靠的做法
绝大多数冲突源于包作者没严格遵循命名空间隔离原则。你不能指望别人改，但可以控制自己怎么加载：
- 检查冲突包的
composer.json中autoload和autoload-dev字段，确认它是否把类映射到了全局或泛用命名空间（比如"": "src/"） - 如果它用了
psr-4但前缀太宽（如"App\": "src/"），而你项目也用App\，那就必然撞车；应优先要求包作者收紧前缀（如"VendorName\Package\": "src/"） - 你自己项目中，绝不要把多个第三方包的源码目录直接塞进同一个命名空间下，哪怕它们看起来“只是工具类”
示例：某包错误地写了 "autoload": {"psr-4": {"App": "src/"}}，而你的项目也是 App，此时 Composer dump-autoload 后，两个 AppHelper 类文件都会被注册进 autoloader，运行即失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
classmap + exclude-from-classmap 是临时止血手段
当无法推动上游修改，又必须集成该包时，可用 classmap 手动覆盖加载路径，或用 exclude-from-classmap 主动屏蔽冲突文件：
-
exclude-from-classmap只在classmap自动扫描时生效，对psr-4无效；所以得先确认那个包用的是哪种 autoload 方式 - 若包用
classmap，可在你项目的composer.json中加："autoload": { "classmap": ["vendor/bad/package/src/"] }, "autoload-dev": {}, "exclude-from-classmap": ["vendor/bad/package/src/Helper.php"] - 注意：排除后该类就彻底不可用，除非你手动
require或另写代理类，别以为只是“跳过加载”
require-dev 和 replace 能防冲突但治标不治本
有些包用 replace 声明自己“替代”另一个包（如 "monolog/monolog": "*"），这会影响依赖解析，但不会阻止运行时类重复加载：
-
replace只在安装阶段起作用，告诉 Composer “别装这个包了”，但如果被替换的包已被其他依赖拉进来，它照样存在、照样注册 autoload -
require-dev里的包默认不参与生产 autoload，但如果你执行了composer install --no-dev，而某个 dev 包的类又被主代码引用了，就会报Class not found—— 这不是冲突，是误用 - 真正要防冲突，得看
composer show -t输出的依赖树，找谁真正引入了那个同名类，再决定是升级、锁定版本，还是 fork 后改命名空间
最常被忽略的一点：Composer 的 autoload 机制本身没有“优先级”或“覆盖”概念，dump-autoload 生成的映射表是扁平的，谁注册得早、谁在 require 链里靠前，谁就先被加载——但 PHP 不允许重定义，所以顺序根本无关紧要，只要两个类同时被 autoload 机制知晓，就注定失败。
