autoload冲突本质是PSR-4命名空间或物理路径重叠，导致类重复声明、覆盖或找不到；常见于自定义目录未显式声明、第三方包autoload与项目撞车、手动require与Composer混用。
autoload冲突的本质是PSR-4路径或命名空间重叠
Composer自动加载冲突不是“加载失败”，而是多个autoload规则指向同一命名空间或物理路径，导致类被重复声明、覆盖或找不到。最常见于：自定义目录未显式声明、第三方包自带autoload且与项目结构撞车、手动require和Composer混用。
检查并统一composer.json中的autoload配置
运行composer dump-autoload --no-scripts前先确认composer.json里只有一处autoload定义（不含autoload-dev），且所有PSR-4映射互不重叠：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
"App\": "app/"和"app\": "app/"是冲突的——大小写敏感，但某些文件系统（如macOS默认）会模糊处理，引发运行时不可预测行为 - 若项目有
extend/目录存放私有扩展，必须显式加进autoload："extend\": "extend/"，否则Composer不会扫描它 - ThinkPHP 6项目应避免在
composer.json中重复声明topthink/think-orm等核心包的autoload，它们已自带完整映射；重复声明可能覆盖原逻辑 - 使用
composer show --tree查某包是否自带autoload：composer show topthink/think-orm | grep autoload，有输出说明它自己注册了规则
清理残留autoload_static.php和手动引入痕迹
旧的autoload缓存文件（尤其是vendor/composer/autoload_static.php）可能保留已删除包的类映射，导致新类找不到或报Class already exists。手动include/require某个类文件后又通过Composer装同名包，也会触发致命错误。
- 删掉整个
vendor/composer/autoload_*.php（注意不是删vendor/目录） - 执行
composer dump-autoload -o重建优化映射 - 全局搜索项目代码，删掉所有
require_once 'vendor/autoload.php'之外的手动require同类库的语句 - 开发环境可加
--no-dev测试：composer dump-autoload --no-dev -o，确认生产级加载无异常
区分TP5.1与TP6的autoload机制差异
ThinkPHP 5.1仍部分依赖框架自身加载器，而TP6完全移交Composer管理。混用会导致双加载或跳过Composer规则。
- TP6项目必须把应用模块（如
app/admin）也注册进composer.json的autoload，例如："app\admin\": "app/admin/" - TP5.1中若用了
Loader::addNamespace()动态注册，需同步在composer.json补上对应PSR-4，否则Composer无法识别 - 升级到TP6时，检查
runtime/下是否有遗留的loader.php或autoload.php，这些文件可能绕过Composer直接加载旧类
"Lib\": "lib/"，而某第三方包也声明了"Lib\": "vendor/some/lib/src"，Composer会按composer.json中声明顺序加载，后者覆盖前者，但你根本不知道。每次改完autoload，务必用composer dump-autoload -v看详细输出，确认每个命名空间只绑定一个路径。 
