composer dump-autoload -o 生成完整 classmap，但仅对路径匹配、单类单文件、无动态定义的类生效；生产环境需配合 --no-dev 和 --classmap-authoritative 才真正提升性能。
composer dump-autoload -o 会生成完整 classmap，但只对满足条件的类生效
composer dump-autoload -o 的核心动作是扫描 autoload 和 autoload-dev 配置里声明的所有路径（包括 vendor/ 中依赖包），把每个「能被静态识别的类」写进一个扁平的 classmap 数组。但它不会处理 PSR-4 下动态拼接路径的类——那些仍走常规查找逻辑。
要进 classmap，必须同时满足：
- 类文件路径与 composer.json 中 psr-4 或 classmap 配置严格匹配
- 单个 PHP 文件只定义一个类（且类名与文件名一致）
- 没有使用 traits、匿名类或条件定义（如 if 块里定义类）
生产环境别只用 -o，要搭配 --no-dev 和 --classmap-authoritative
单独加 -o 在现代 Composer 2+ 中效果有限：它默认仍保留 fallback 查找机制，遇到 classmap 里没有的类，还是会去遍历目录。真正关闭 fallback、强制只查 classmap 的是 --classmap-authoritative。
推荐生产部署命令是：composer install --no-dev --optimize-autoloader --classmap-authoritative
这三者缺一不可：
- --no-dev 排除 autoload-dev 路径（比如 tests/），减少 classmap 体积和构建时间
- --optimize-autoloader 等价于 -o，触发 classmap 扫描
- --classmap-authoritative 让 autoloader 把 classmap 当唯一来源，跳过所有文件系统探测
为什么有时加了 -o 还报 Class not found？
常见原因不是命令没跑，而是 classmap 根本没覆盖到那个类：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 类在
psr-4路径下，但命名空间声明错误（比如namespace App/Models;少了反斜杠） - 类文件放在了
autoload未声明的目录（如直接丢在项目根目录） - 用了
classmap配置，但路径写的是相对路径而非相对于composer.json的路径 - PHP opcache 启用但未清理，缓存了旧的 autoload 文件
验证方式：打开 vendor/composer/autoload_classmap.php，搜索类名，看是否出现在数组里。
开发阶段通常不需要 -o
开发时频繁增删类，-o 生成的 classmap 会很快过期；而且 PSR-4 的路径映射本身足够快，file_exists() 开销远低于实际文件加载。盲目加 -o 反而让 dump-autoload 变慢（尤其 vendor 包多时），还可能掩盖命名空间配置错误。
日常开发只需：composer dump-autoload
遇到类找不到，优先检查命名空间、文件位置、composer.json 配置是否同步，而不是立刻加 -o。
真正关键的不是加不加 -o，而是 classmap 是否权威、dev 配置是否被排除、opcache 是否刷新——这些点漏掉一个，-o 就只是个安慰剂。
