psr-4映射必须严格对齐命名空间与目录结构，末尾反斜杠不可省略，"src/"为相对composer.json路径；classmap适用于无命名空间旧代码，files用于前置加载函数/常量，autoload-dev需配合--no-dev控制且ci易失效。
psr-4 映射必须严格对齐命名空间与目录结构
“App\”: “src/” 这种写法不是约定俗成，而是硬性规则：末尾的 \ 是转义后的真实反斜杠，漏掉就变成 App" 字符串，整个映射静默失效；"src/" 是相对于 composer.json 所在路径，不是项目根目录也不是 vendor/。常见错误包括：
-
"App\": "src/App/"→ 导致App\User去找src/App/User.php，但实际类在src/User.php - 命名空间写成
App\Http\Controllers，但目录是src/http/controllers/（Linux 下大小写敏感，直接Class not found） - 文件名不匹配类名：比如
src/Http/Client.php里定义了class HttpClient，PSR-4 不会识别
classmap 适合无命名空间或结构混乱的老代码
classmap 不走命名空间推导，只扫描你指定的路径或文件，把所有 class、interface、trait 声明提取出来建表。它不挑文件名、不认命名空间，但代价是每次增删类都得手动运行 composer dump-autoload。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 适合场景：全局工具函数文件（如
helpers.php）、旧版Foo_Bar类、数据库封装类等不遵循 PSR 的代码 - 配置示例：
"classmap": ["legacy/", "src/utils/functions.php"] - 别对大目录扫：
"classmap": ["vendor/"]会卡死生成过程，且毫无必要 - 加
-o优化后，classmap被合并进autoload_classmap.php，但新增类不会自动补入——调试阶段建议不用-o
files 加载顺序固定，但不能用来定义类
files 是唯一一种“每次 require 'vendor/autoload.php' 就立即 require_once”的方式，它总在 PSR-4 和 classmap 之前执行，由 Composer 硬编码控制。
- 只放真正需要前置加载的东西：常量定义、全局函数、
define()、function_exists()检查等 - 路径必须是相对于
composer.json的完整路径，比如"src/helpers.php"，不能写成"./src/helpers.php"或"helpers.php" - 数组内顺序即加载顺序：如果
a.php依赖b.php里的函数，b.php必须写在前面 - 严禁在
files里require类文件——会导致和 PSR-4 同名类重复定义，报Fatal error: Cannot declare class X
autoload-dev 隔离测试类，CI 环境下极易失效
autoload-dev 区块只在 require-dev 已安装、且未使用 --no-dev 时才生效。CI 构建脚本若默认加了 --no-dev，那 "Tests\": "tests/" 整个映射就不存在。
- PHPUnit 自动发现测试类依赖这个映射，映射错或没生效 →
Class 'Tests\TestCase' not found - 测试类本身不能塞进主
autoload，否则上线包白带一堆测试代码 - 测试类要引用
src/下的类？确保主autoload的 PSR-4 已正确定义，autoload-dev只管自己那块 - 验证方式：在 CI 环境跑
composer show --platform或临时加一行var_dump(class_exists('Tests\TestCase'))
composer.json 不运行 composer dump-autoload，等于什么都没做；运行了但不在 composer.json 所在目录执行，也等于白干。最隐蔽的坑是 Windows 开发、Linux 部署时路径大小写不一致，或者 __autoload 函数残留覆盖了 Composer 的加载器。
