composer dump-autoload -o 本身不提速，需配合 --classmap-authoritative 和 --no-dev 并确保类被正确收录进 autoload_classmap.php，同时清理 ThinkPHP 类缓存与 OPcache。
composer dump-autoload -o 本身不提速——它只生成 autoload_classmap.php，但默认仍走 PSR-4 fallback，类没进 classmap 表里，该慢还是慢。
怎么确认 classmap 真生效了
别只看命令有没有报错，关键看你的类是否真被收进映射表：
打开 vendor/composer/autoload_classmap.php，搜索类似 appordermodelOrder 这样的完整类名。如果没出现，说明优化根本没覆盖到你自己的代码。
常见失效原因：
-
app/目录默认不在classmap里，必须手动加进composer.json的"classmap"字段 - 命名空间声明少了个反斜杠，比如写成
"App": "app/"而不是"App\": "app/"，Composer 扫描器直接跳过整个目录 -
composer dump-autoload -o没带-a（--classmap-authoritative），导致找不到类时仍 fallback 到 PSR-4 扫描
classmap 该加哪些路径，不该加哪些
加错路径比不加还糟：classmap 是静态全量扫描，每次执行都要遍历目录下所有 PHP 文件。所以它只适合「稳定、极少变更」的模块。
- ✅ 推荐加：
library/Utils/、vendor/mycorp/sdk/src/、common/（若业务稳定） - ❌ 绝对别加：
app/整体（开发中高频增删改）、tests/、examples/、vendor/autoload-dev下的路径 - ⚠️ 折中方案：若
app/确实稳定，可加，但必须同步在composer.json中移除重复的psr-4声明，避免同一类注册两次
为什么关掉 thinkinitializerError 能明显提速
这个初始化器在 TP6+ 默认启用，但它干的是「出错才补救」的事：
第一次抛异常时，它会从调用栈里反向提取类名，再触发一次自动加载——相当于在错误路径上又跑一遍文件系统扫描 + 正则匹配。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 关闭方式：在
config/app.php中设'error_handler' => false - 更彻底的关法：在应用初始化阶段把
hinkinitializerError::class => null - 注意：这不影响日志记录，只是去掉非必要环节；如果你依赖自定义
__autoload补充逻辑，才需评估
生产环境必须配齐的三个参数
单独跑 composer dump-autoload -o 在线上几乎无效。真正起效的是这条组合命令：
composer dump-autoload -o --classmap-authoritative --no-dev
-
--classmap-authoritative：强制只查autoload_classmap.php，找不到就报错，彻底砍掉 fallback 的file_exists()开销 -
--no-dev：排除autoload-dev里的测试路径，避免无谓扫描 - 缺一不可：漏掉
--classmap-authoritative，fallback 还在；漏掉--no-dev，测试类混进映射，体积膨胀且易出错
最后务必清空 ThinkPHP 的类缓存（runtime/cache/*_class.php）和 OPcache（opcache_reset() 或重启 PHP-FPM），否则旧的未优化映射还在内存里跑。classmap 文件本身也要被 OPcache 缓存住，否则每次请求都重新解析几 MB 数组，反而更慢。
