生产环境必须用composer install --no-dev --optimize-autoloader --classmap-authoritative，该命令在安装阶段完整扫描autoload路径生成autoload_classmap.php并启用权威加载；仅dump-autoload -o不重建classmap、不触发扫描、不启用权威模式，易致类漏映射和Class not found。
composer install --optimize-autoloader 不生成 classmap？先看 autoload_classmap.php 是否真被写入
它确实会生成类映射，但只在满足条件时才真正写入 vendor/composer/autoload_classmap.php。常见错误是执行完命令后该文件仍为空或只有几 KB —— 这说明 Composer 根本没扫描到任何可映射的类。
原因通常是：composer.json 中 autoload 块未正确定义 PSR-4 路径，或路径末尾缺反斜杠（如 "App": "app" 错误，应为 "App\": "app/"）；又或者目录下类文件命名不规范（含点号、下划线、非 .php 后缀），导致扫描跳过。
- 确保
autoload.ps4或autoload.classmap显式声明了所有生产用源码路径，比如"App\": "app/"、"Support\": "support/" - 删掉
vendor/composer/autoload_classmap.php再运行composer install --no-dev --optimize-autoloader，避免 Composer 因文件存在而跳过重建 - 检查生成后的
autoload_classmap.php大小：含数百个类时应在几十 KB 级别；若仍很小，说明扫描失败，不是参数无效
为什么 dump-autoload -o 比 install --optimize-autoloader 更容易失效
composer dump-autoload -o 只重写 autoload 文件，不重装依赖，也不强制触发完整 classmap 扫描逻辑。尤其在 Composer 2.2+ 中，它默认只刷新轻量映射，甚至不生成 autoload_classmap.php，而是走 autoload_static.php 的静态数组路径 —— 这个数组本身不包含全量类路径，只缓存了部分 PSR-4 映射结果。
更关键的是：dump-autoload -o 不自动启用 --classmap-authoritative，所以即使有 classmap，findFile() 里仍保留大量 foreach 和 file_exists() 调用，根本没跳过文件系统。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer install --no-dev --optimize-autoloader是唯一能保证在安装阶段完整扫描所有 autoload 声明路径的命令 -
dump-autoload -o适合本地快速刷新，但 CI/CD 或生产部署必须用install命令 +--no-dev - 若你改了
composer.json的 autoload 配置，仅dump-autoload不会重新读取 vendor 包里的 autoload 声明 ——install会
加了 --classmap-authoritative 为什么还报 Class not found
这不是配置错，是 classmap 漏了类。加了 --classmap-authoritative 后，ClassLoader 彻底放弃 PSR-4 fallback：找不到就直接抛 Class not found，连拼路径、调 is_file() 都省了。
典型漏类场景包括：测试类放在 tests/ 但没在 autoload.classmap 里声明；私有工具类在 src/Utils/，但 autoload.ps4 只写了 "App\": "app/"；框架启动时调用 addClassMap() 动态注册，让权威模式退化。
- 验证是否生效：打开
vendor/composer/autoload_real.php，搜索findFile()方法 —— 正常应只剩if ($classMap = $this->classMap)分支，没有foreach循环 - 用
strace -e trace=openat php -r 'new AppHttpControllerHomeController();'观察系统调用：优化后应只剩 2–3 次openat，而非几十次 - 若报错，别急着改配置，先跑
composer dump-autoload --optimize --classmap-authoritative并确认autoload_classmap.php里有没有对应类名
OPcache 没配好，再优化也白搭
--optimize-autoloader 生成的 autoload_static.php 和 autoload_classmap.php 是 PHP 数组文件，它们要靠 OPcache 缓存编译结果才能发挥最大效用。否则每次请求都要重新解析几十 KB 的数组，反而比少量 file_exists() 更慢。
典型表现是压测前几次响应明显延迟，后续才稳定 —— 说明 OPcache 还没热起来。
- 确认
opcache.enable=1且opcache.enable_cli=1（CLI 场景也需要） -
opcache.memory_consumption至少设为 128M，否则大项目的 autoload 文件可能被挤出缓存 - 禁用
opcache.validate_timestamps=1（开发环境除外），否则每次请求都检查文件修改时间 - 部署后手动执行
opcache_reset()或重启 PHP-FPM，确保新 autoload 文件被加载进缓存
--optimize-autoloader 就只是个摆设。 
