Composer自动加载是PHP项目运行的底线条件，必须在入口文件首行require 'vendor/autoload.php'并执行composer dump-autoload更新映射表，PSR-4配置需严格匹配命名空间与路径末尾的反斜杠/斜杠。
Composer 自动加载不是“锦上添花”，而是 PHP 项目能跑起来的底线条件——漏掉 require 'vendor/autoload.php'，或改了 composer.json 却不执行 composer dump-autoload，90% 的 “Class not found” 错误就源于此。
为什么 require 'vendor/autoload.php' 必须写在入口文件第一行
这行代码不是“引入一个文件”，而是触发整个自动加载链的启动开关。它内部调用 ClassLoader::getLoader()，并通过 spl_autoload_register() 把 PSR-4、classmap 等加载逻辑注册进 PHP 的 autoload 队列。
常见错误现象：
- 入口文件里先
new AppController()，再require 'vendor/autoload.php'→ PHP 在实例化时还没注册任何加载器，直接报错 - 框架启动前用了自定义
__autoload且返回false→ 拦截了后续 Composer 加载器 - CLI 脚本里漏掉这行，却在测试中“偶然”跑通 → 因其他依赖已提前加载过该类，具有强迷惑性
改了 composer.json 的 psr-4 配置，为什么类还是找不到
vendor/autoload.php 只是启动器，真正干活的是它加载的 vendor/composer/autoload_psr4.php —— 这个文件是静态生成的映射表，不会监听文件变化。
必须手动执行：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer dump-autoload：重生成autoload_psr4.php、autoload_classmap.php等文件 - 改了命名空间映射（如
"App\": "src/"）却不运行该命令 → 配置等于没改 - 手动编辑过
vendor/composer/autoload_psr4.php→ 下次dump-autoload会被覆盖，白改
PSR-4 映射路径和命名空间末尾的反斜杠/斜杠为什么不能省
它们不是风格问题，而是拼接逻辑的锚点：
- 命名空间写成
"App"（缺）→ 匹配不到AppControllerUserController，因为前缀不完整 - 路径写成
"src"（缺/）→ 拼出srcController/UserController.php，而不是src/Controller/UserController.php，直接 404 - 正确写法只能是
"App\": "src/"（注意 JSON 中双反斜杠实际表示单反斜杠） - Linux 下大小写敏感：文件名是
UserController.php，但类定义为class usercontroller或文件保存为usercontroller.php→ 加载失败
classmap 和 PSR-4 混用时最易忽略的陷阱
两者共存时，加载优先级固定：先查 PSR-4 前缀匹配，未命中才 fallback 到 classmap 全局查表。
但风险在于：
- classmap 是“暴力扫描型”：配置
"lib/"后，Composer 会递归扫描所有.php文件，正则提取class/interface/trait名并记录绝对路径 - 一旦类文件被移动或删除，不重新运行
composer dump-autoload→ classmap 仍指向旧路径，“加载的是删掉的文件” - 用了
--classmap-authoritative却忘了更新 classmap → 找不到类时直接报错，不再尝试 PSR-4 或其它加载方式
自动加载机制本身不复杂，但每个环节都卡在“必须显式触发”和“严格字符串匹配”上——少一次 dump-autoload，多一个反斜杠遗漏，或一行 require 放错位置，整个链就断了。这不是配置问题，是执行契约。
