autoload 字段必须放在 composer.json 根对象顶层，与 require 同级而非嵌套在 extra 等字段中；修改后需运行 composer dump-autoload 生效。

autoload 字段写在哪？不是 composer.json 顶层

它必须放在 composer.json 的根对象里，但不是和 name、require 并列的“一级字段”——而是和它们同级。常见错误是把它塞进 extra 或 scripts 里，结果完全不生效。

• 正确位置：composer.json 顶层，与 require 同级
• 错误位置：extra.autoload、config.autoload、scripts.post-autoload-dump（后者只是钩子，不定义规则）
• 写完必须运行 composer dump-autoload 才能生效，改了不重生成，代码照样报 Class not found

psr-4 和 classmap 用哪个？看文件结构是否规整

psr-4 是默认推荐，但前提是你的目录命名和命名空间严格对应；一旦有历史遗留的非标准路径、函数文件或全局常量，就得切到 classmap。

Workflow Decomposer

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

下载

• psr-4：适合现代 PHP 项目，比如 "App\": "src/" 要求 src/Controller/HomeController.php 里声明 namespace AppController
• classmap：适合老项目、含 .php 函数库、或路径和命名空间错位的情况，比如 "files": ["lib/helpers.php"] 或 "classmap": ["legacy/"]
• 混用允许，但别在同一个命名空间下既用 psr-4 又用 classmap，Composer 会优先走 psr-4，后者的类可能被忽略

files 数组加载的是函数，不是类，且只加载一次

files 用于引入全局函数或常量定义文件，在 Composer 自动加载启动时执行一次。它不支持按需加载，也不参与类查找逻辑。

• 典型场景："files": ["src/functions.php", "src/constants.php"]
• 不能放类文件——即使里面写了 class，也不会被自动实例化，new Foo() 仍会失败
• 重复包含无副作用，但性能上不如 classmap 高效；大项目慎用过多 files，每次请求都 require
• 注意路径是相对于 composer.json 的，不是相对于当前工作目录

autoload-dev 和 autoload 不是互斥关系，而是叠加关系

开发依赖的自动加载规则（如测试类）不会覆盖主 autoload，而是额外追加。但很多人误以为 autoload-dev 只在 composer install --dev 时生效——其实只要没加 --no-dev，它就一直有效。

• autoload-dev 中的 psr-4 规则，和 autoload 中的规则共存，命名空间不冲突即可
• 常见坑：tests/ 映射到 Test\，但生产环境不需要这些类，却忘了在部署时加 --no-dev，导致测试代码意外进入线上 autoloader
• 运行 composer dump-autoload --no-dev 会清掉 autoload-dev 规则生成的映射，这点容易被忽略

实际项目里最麻烦的不是写错字段，而是改了 autoload 后没清 vendor/composer/autoload_*.php，或者没跑 dump-autoload 就去测 —— 这时候报错永远指向旧路径。