生产环境必须用composer install --no-dev --optimize-autoloader --classmap-authoritative --no-interaction --prefer-dist：dump-autoload -o不重建autoload_classmap.php，仅刷新轻量文件；classmap只在install/update时生成，且--classmap-authoritative才是跳过fallback、实现真正加速的关键，单独-o无效。
生产环境必须用 composer install --no-dev --optimize-autoloader --classmap-authoritative --no-interaction --prefer-dist，少一个参数，autoload 就可能退化、类加载慢几倍，甚至报 Class not found。
为什么 composer dump-autoload -o 基本无效
它不重建 vendor/composer/autoload_classmap.php，只刷新轻量级的 autoload_static.php 和 PSR-4 映射表。真正的 classmap 只在 install 或 update 阶段生成。
- 执行后检查
autoload_classmap.php：文件不存在或大小为 0 → 没生效 - 即使存在，若
composer.json中没声明"classmap"数组，Composer 2.x 会跳过扫描，-o是空转 - PHP 7.4+ 下全量 classmap 反序列化开销大，而实际请求只用到其中不到 5% 的类，内存和 CPU 反而吃亏
--optimize-autoloader 和 --classmap-authoritative 必须成对出现
单独用 --optimize-autoloader（或 -o）几乎无效：它只把 PSR-4 映射转成静态数组，但 autoloader 仍会 fallback 到目录扫描；真正跳过 file_exists() 和 stat() 的，是 --classmap-authoritative。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
--classmap-authoritative不是“加速开关”，而是“断电式加载”：类不在 classmap 里就立刻失败，不尝试任何 fallback - 报
Class not found不是配置错，是 classmap 漏了类 —— 检查vendor/composer/autoload_classmap.php里有没有你新加的App\Console\Commands\DeployCommand -
"classmap-authoritative": true必须写进composer.json的config块，否则composer update后可能丢失
部署脚本里怎么写才不翻车
CI/CD 流水线里最常见错误：lock 文件没 commit、本地手动 update 后忘推、或用 dump-autoload -o 替代 install —— 后者在 Composer 2+ 中已失效，生成的 classmap 极可能不全。
- 务必先
git checkout $TAG，再跑composer install，确保代码与composer.lock版本一致 - 加
--no-interaction -n防卡在插件启用提示，加--prefer-dist强制下 zip 包，避免git clone失败 - 完整命令：
composer install --no-dev --optimize-autoloader --classmap-authoritative --no-interaction --prefer-dist -
opcache.enable_cli=1是优化生效的隐形门槛 —— 某些 Docker 镜像或自定义 ini 会关掉它
最容易被忽略的是 --classmap-authoritative 的语义：它不是“更快”，而是“更严格”。一旦开启，所有类必须出现在 classmap 中，否则直接失败。而 classmap 是否完整，取决于 PSR-4 命名空间末尾有没有反斜杠、新增类是否严格匹配目录结构、以及 autoload-dev 是否污染了主 autoload 块 —— 这些细节一漏，线上就报错，且很难定位。
