autoload-dev 与 autoload 是两套独立配置，互不继承覆盖；前者仅在开发环境生效，后者始终生效；部署时必须加 --no-dev 才能禁用 autoload-dev。
autoload-dev 字段只影响 composer install --no-dev 时是否加载开发用的类，和“自动加载逻辑本身”无关——它不改变 autoload 的规则，只是开关一扇额外的门。
autoload-dev 和 autoload 是两套独立配置
很多人误以为 autoload-dev 是 autoload 的“子集”或“补充”，其实不是。它们各自声明自己的映射，互不继承、不合并、不覆盖。Composer 会把两者都注册进 autoloader（除非你加了 --no-dev）。
-
autoload中的路径在生产/开发环境都会生效 -
autoload-dev中的路径仅在开发环境（即没加--no-dev）才生效 - 如果同一命名空间在两边都定义了，
autoload-dev不会覆盖autoload，而是并存——PHP 自动加载器按注册顺序查找，先命中谁就用谁
常见写法：psr-4 + 测试类路径
最典型场景是把 tests/ 下的测试类映射到 Tests 命名空间，且只在开发时可用：
{
"autoload": {
"psr-4": {
"App\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"Tests\": "tests/"
}
}
}
注意：Tests 后面必须带反斜杠，否则 Composer 会报错 Invalid PSR-4 rule；路径 tests/ 必须真实存在，否则 composer dump-autoload 不报错但运行时找不到类。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
容易踩的坑：classmap + 目录权限与生成时机
如果用 classmap 方式写 autoload-dev，比如：
"autoload-dev": {
"classmap": ["tests/helpers/", "stubs/"]
}
- 这些目录下的文件必须是 PHP 文件（
.php），Composer 不识别.inc或无后缀文件 -
composer dump-autoload会扫描并生成映射，但如果目录不可读（如权限为 000 或被 gitignore 排除），Composer 就静默跳过——不会报错，但类就是加载不到 -
classmap不支持命名空间推导，所有类必须有namespace声明，否则加载失败时错误信息是Class XXX not found，而不是更具体的提示
为什么 vendor/autoload.php 里总能加载 dev 类？
因为默认 composer install 不带 --no-dev，所以 autoload-dev 配置会被载入。但上线部署时，CI/CD 脚本若漏掉 --no-dev，就会把测试类、Mock 工具、调试工具一起打进生产环境——不仅增大体积，还可能因意外调用暴露敏感逻辑。
真正要检查的不是怎么写，而是部署命令里有没有这行：composer install --no-dev --optimize-autoloader。少一个 --no-dev，autoload-dev 就白设了。
