Composer的-o参数仅优化classmap加载器，若未在composer.json中显式配置"classmap"字段或遗漏目录，则无法覆盖全部类；需配合--classmap-authoritative和APCu缓存并调优配置才能真正提速。
为什么 composer dump-autoload -o 有时没提速？
因为 -o（--optimize）只优化 classmap 加载器，而默认的 PSR-4 是靠运行时拼路径 + is_file() 查文件——它根本绕不开磁盘 I/O。如果你的 composer.json 里没配 "classmap" 字段，也没在 "autoload" 中声明所有含类的目录，-o 就只是把已知的 PSR-4 映射“转成数组”，但漏掉的类依然得走慢路径。
- 必须显式配置
"classmap": ["src/", "app/", "lib/"]，否则 Composer 不会扫描这些目录生成 classmap - 测试目录（
tests/）、私有工具类（src/Utils/）若没写进classmap或psr-4，就永远不会被扫到 - 带下划线或点号的文件名（如
My_Controller.php）会被跳过——classmap 扫描只认标准class、interface、trait声明，不依赖文件名
怎样让 classmap 真正覆盖全部类？
别指望自动发现，得主动收口。Composer 的 classmap 生成逻辑很老实：你指哪，它扫哪，不多也不少。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 删掉冗余的 PSR-4 配置，如果
src/下全是规范命名空间，直接全切到classmap：省去路径拼接、realpath()、大小写转换等开销 - 在
composer.json中写死关键路径："classmap": ["src/", "app/Exceptions/", "database/factories/"] - 用
composer dump-autoload -a（--classmap-authoritative）强制重扫——比-o更彻底，且生成后自动启用权威模式 - 检查
vendor/composer/autoload_classmap.php，确认你要用的类名（如'App\Http\Controllers\HomeController'）已映射到正确路径
APCu 缓存开了还是慢？先看这三件事
APCu 不是银弹，配错等于没开。classmap 本身是 O(1) 数组查找，瓶颈往往卡在缓存没生效或 PHP 层外。
- 确认
apc.enabled=1且apc.stat=0——否则每次require都会stat文件，classmap 白优化 -
classmap数组不会被 APCu 缓存；真正要缓存的是 autoloader 实例，得靠composer install --apcu-autoloader或运行时手动设前缀：$loader->setApcuPrefix('myapp'); - 检查
apc.shm_size是否够用（比如 classmap 超 5000 行，64M 可能吃紧），不够就调大
生产部署该跑哪条命令？
别单独跑 dump-autoload -o，它不校验 composer.lock，也不剔除 dev 依赖，容易出环境差异。
- 标准做法是：
composer install --no-dev --optimize-autoloader --classmap-authoritative -
--no-dev减小 autoload 文件体积，避免加载测试类污染生产 -
--classmap-authoritative告诉 autoloader：“所有类都在 classmap 里”，找不到直接报错，跳过所有其他加载器（PSR-4/PSR-0/files），大幅减少文件系统调用 - 这条命令会自动触发
dump-autoload，且比手动生成更安全
