classmap 生成后 autoloader 仍慢，因其仅静态生成且不自动感知新增类，未重跑 dump-autoload 时会回退 psr-4 扫描；需确认 classmap 是否生效、合理启用范围、避免大小写/路径错误，并权衡体积与性能。
classmap 生成后为什么 autoloader 还是慢？
因为 classmap 只在 composer dump-autoload 时静态生成一次，它不会自动感知后续新增的类文件。如果你改了代码但没重跑命令，autoloader 仍会 fallback 到 PSR-4 扫描——尤其当包里混用多种加载方式时。
- 确认是否真用了 classmap：检查
vendor/composer/autoload_classmap.php是否包含目标类名（比如'SomeBigPackage\Helper' => $vendorDir . '/some/big-package/src/Helper.php'） - 只对「稳定、极少改动」的目录启用 classmap，比如
src/下已封版的工具类，别对tests/或examples/目录加 - 运行
composer dump-autoload --classmap-authoritative强制关闭 PSR-4 fallback，能压测真实 classmap 效果，但上线前务必验证所有类都能命中
哪些包适合手动加 classmap？
不是所有大包都值得动 classmap。重点看两类：一是历史包袱重、目录结构混乱的老包（比如某些 Symfony Bundle 的 legacy 子模块），二是你只用其中几个类，但 PSR-4 扫描会遍历几十个子目录。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 典型场景：
monolog/monolog默认走 PSR-4，但若项目只用MonologLogger和MonologHandlerStreamHandler，可把src/Monolog/Logger.php和src/Monolog/Handler/StreamHandler.php单独拎进 classmap - 避免对整包加：
"classmap": ["vendor/monolog/monolog/src/"]会把所有类塞进 classmap，反而增大 autoload 文件体积，得不偿失 - 优先改
composer.json的autoload段，而不是依赖autoload-dev或第三方插件
classmap 和 PSR-4 共存时的优先级陷阱
Composer 加载类时，classmap 是最高优先级，但前提是类名完全匹配。一旦命名空间或大小写有偏差，就会跳过 classmap 直接走 PSR-4——这时你根本意识不到 classmap 生效了，还误以为“没起作用”。
- 常见错误：
"classmap": ["src/Utils/"]里有个Utils/StringHelper.php，但类声明是class stringhelper（小写），classmap 条目会是'stringhelper' => ...，而new StringHelper()就找不到 - 验证方法：用
composer show -s看 autoload 映射摘要，再用php -r "var_dump(composerAutoloadClassLoader::getRegisteredLoaders());"查实际注册的映射数组 - Windows 下路径分隔符不敏感，Linux/macOS 严格区分大小写，classmap 生成结果可能跨平台不一致
生产环境 classmap 的体积与冷启动代价
classmap 文件本质是 PHP 数组，越大越占内存。一个含 5000 个类的 classmap，autoload 文件可能超 2MB，PHP 解析时会多耗几毫秒——对 CLI 命令影响不大，但对高频短生命周期的 FPM 请求，就是实打实的开销。
- 用
composer dump-autoload --optimize（即-o）会合并 classmap + 优化 PSR-4 映射，比纯--classmap-authoritative更平衡 - 别在开发环境盲目开
--classmap-authoritative：IDE 自动补全、动态类加载（如测试中 mock 类）可能失效 - 真正要压榨性能的地方，是减少「被加载但永不执行」的类——比如把
vendor/里某包的bin/目录排除在 autoload 外，比硬塞 classmap 更有效
