classmap配置需执行composer dump-autoload才生效，因其依赖静态映射表而非实时扫描；增删改类文件或修改composer.json的classmap字段均须手动重建映射。
classmap配置必须执行composer dump-autoload才生效
classmap不是实时扫描目录的机制，它依赖静态映射表。你改完composer.json里的"classmap"字段、新增类文件、甚至删了旧类，都不影响已生成的autoload_classmap.php——除非手动触发重建。
常见错误现象：Class 'ClassA' not found，但文件明明在libs/ClassA.php里，且composer.json已加"libs/"进classmap数组。
- 必须运行
composer dump-autoload（开发阶段）或composer dump-autoload --optimize（生产部署） - 如果只改了类文件内容但没改文件名或路径，不需重跑；但只要增/删/移动了类文件，就必须重跑
-
composer install或update默认不重建classmap，除非加--optimize-autoloader标志
classmap支持无命名空间和带命名空间的类混用
classmap不解析命名空间，只做「类名 → 文件路径」的硬映射。所以ClassA、App\Utils\Helper、Vendor\Legacy\OldClass都能塞进同一个classmap目录下，Composer全认。
使用场景：迁移老项目时，有大量无命名空间的类，或第三方SDK未遵循PSR标准（比如直接class WeChatAPI），这时用classmap比强行改命名空间+目录结构更省事。
- 目录内可嵌套子目录，
classmap值填目录路径即可，Composer会递归扫描所有.php文件 - 同一个类名不能出现在多个路径下，否则
autoload_classmap.php里后扫描到的会覆盖前面的（PHP数组键唯一） - 若两个不同命名空间下存在同名类（如
MyApp\User和Legacy\User），classmap仍能区分——因为键是完整类名，包括反斜杠
classmap性能优于PSR-4，但灵活性差
classmap加载快，是因为autoload_classmap.php本质是个大数组['ClassName' => '/abs/path/to/file.php']，查找是O(1)哈希操作；而PSR-4要拼路径、检查文件是否存在，是多次I/O。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
但代价是：每次增删类都要重生成映射，不适合热更频繁的开发环境；也不能像PSR-4那样靠命名空间前缀自动适配新类。
- 生产环境强烈建议启用
"optimize-autoloader": true（写在composer.json根级），这样composer install --no-dev会自动触发--optimize - 不要把整个
vendor/塞进classmap——Composer自己管理的包已优化，重复加入反而拖慢dump速度 - 如果类文件极少（"files"方式require单个文件可能更轻量
classmap路径必须是相对项目根目录的路径
composer.json中classmap数组里的路径，是相对于该文件所在目录（即项目根）的相对路径，不是相对于vendor/autoload.php，也不是绝对路径。
典型错误："classmap": ["./src/libs/"] 或 "classmap": ["/var/www/myapp/src/libs/"] ——前者./多余，后者绝对路径会导致dump-autoload失败并报错Invalid classmap path。
- 正确写法：
"classmap": ["src/libs/", "legacy/"] - 路径末尾斜杠可加可不加，但建议统一加，避免误判为文件
- 路径不能以
../开头，不能跨出项目根目录（Composer会拒绝）
classmap最易被忽略的点是：它不校验类名是否匹配文件内容。哪怕Foo.php里写的是class Bar，只要这个文件被扫进去了，映射就建在'Bar'上——运行时报错会晚于加载阶段，调试时容易绕弯。
