classmap扫描旧类文件需显式指定目标目录（如"legacy/"），路径须相对composer.json且排除vendor等干扰目录，否则映射膨胀或加载错版本。
classmap 怎么扫旧类文件才不翻车
classmap 是加载无命名空间、文件名乱、目录结构野的旧代码最稳的方式，但它不是“放进去就认”，关键在路径写法和扫描范围。常见错误是写成 "classmap": ["."]，结果把 vendor/、tests/、node_modules/ 全扫一遍，映射表膨胀、加载变慢，甚至因同名类（比如两个 User.class.php）导致线上加载错版本。
正确做法是显式指定目标目录：
-
"classmap": ["legacy/", "lib/", "src/utils.php"]—— 目录会递归扫描，单个文件也能直接写 - 路径必须相对于
composer.json所在目录，不能写./legacy/或legacy（缺斜杠） - 如果真要扫整个项目但排除某些目录，得配合
exclude-from-classmap字段，例如：{"autoload": {"classmap": ["."] },"exclude-from-classmap": ["vendor/","tests/","node_modules/"] }
files 为什么不能塞类文件进去
files 的作用是每次请求时无条件 require_once 指定文件，它压根不参与类查找流程，只做静态包含。你把它当类加载器用，等于在火药桶边点烟——典型误用是把 UserService.php 放进 files，结果一运行就报 Fatal error: Cannot declare class UserService。
只该放三类东西：
- 纯函数定义文件，如
src/functions.php - 常量配置文件，如
config/constants.php - 需要全局初始化的脚本（注意副作用），如
bootstrap/legacy-init.php
路径必须是相对于 composer.json 的完整路径，不能写 functions.php；多个文件加载顺序不可控，有依赖关系时建议改用 classmap 或封装成类。
PSR-4 和 classmap 同时存在时谁赢
Composer 加载类的顺序是固定的：先查 psr-4，再查 psr-0（已废弃），最后 fallback 到 classmap 和 files。这意味着即使某个类同时出现在 psr-4 映射和 classmap 中，只要命名空间匹配成功，就永远走 psr-4 路径，classmap 那条记录等于没用。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
这个优先级设计容易掩盖配置问题：比如你把 AppUser 类放在 app/User.php，却在 composer.json 里写成 "App": "src/"，结果 psr-4 查不到，才退到 classmap——你以为是 classmap 生效了，其实是 psr-4 配错了。
验证方法：
- 检查
vendor/composer/autoload_psr4.php里有没有对应映射 - 搜索
vendor/composer/autoload_classmap.php里有没有该类名
改完配置后不 dump-autoload 就等于没改
classmap 不是实时扫描机制，它依赖静态映射表。你改完 composer.json 的 classmap 字段、新增类文件、甚至删了旧类，都不影响已生成的 autoload_classmap.php——除非手动触发重建。
开发阶段执行：
composer dump-autoload生产环境推荐：
composer dump-autoload -o --classmap-authoritative后者强制 Autoloader 只信 classmap 表，跳过所有运行时目录扫描，但前提是
composer.json 里真有 classmap 配置，且没被动态注册覆盖（比如框架启动时调用 addClassMap()）。
最容易被忽略的一点：CI/CD 流程中必须显式加入 composer dump-autoload，不能指望 composer install 自动触发——它只在锁文件变更或首次安装时 dump，改代码不触发。
