-a 隐含 -o 且强制关闭 PSR-4 回退，未命中即报错；-o 单独使用仍保留兜底查找。Composer 2.x 推荐直接用 -a，生产应通过 composer install --no-dev --optimize-autoloader 统一生成权威 classmap。
composer dump-autoload -o 和 -a 本质是“优化程度递进”，不是并列选项
-o（--optimize）生成完整 classmap，把所有类、接口、trait 的路径预先登记到 vendor/composer/autoload_classmap.php；-a（--classmap-authoritative）则在此基础上**强制关闭回退机制**——如果 classmap 里查不到某个类，Composer 就直接报错，不再尝试按 PSR-4 规则去文件系统里找。
也就是说：-a 隐含了 -o 的行为，但 -o 单独用时仍保留“fallback 到 PSR-4”的兜底逻辑。两者不是互斥关系，而是 -a 更激进、更严格。
- 只用
composer dump-autoload -o：安全，兼容性强，适合开发环境验证 classmap 是否生成成功 - 必须配
-a才能真正压榨性能：跳过所有文件系统stat()调用，类加载完全变成数组查找 - Composer 2.x 中，
-o已被标记为“软弃用”，官方推荐直接用-a或--classmap-authoritative
什么时候会因 -a 报错？这是设计行为，不是 bug
启用 -a 后出现 Class "Xxx" not found，大概率不是命令没生效，而是 classmap 没覆盖到那个类——常见原因包括：
- 类文件在
composer.json的autoload或autoload-dev配置之外（比如放在scripts/或临时目录） - 类名未遵循 PSR-4 命名规范，或命名空间与目录结构不匹配，导致扫描失败
- 用了
--no-dev但该类实际定义在autoload-dev下（如测试工具类） - PHP 文件里有语法错误，Composer 扫描时跳过该文件（不会报错，但也不会写入 classmap）
验证方法：打开 vendor/composer/autoload_classmap.php，搜索类名，看是否存在对应映射。没有，就说明扫描阶段已遗漏。
性能差异实测：-a 比 -o 多省下的是“兜底查找”开销
单次类加载，-o 和 -a 的耗时差距可能只有微秒级；但在高并发或 CLI 脚本频繁启动场景下，累积效应明显：
- 典型 Laravel 应用启动阶段，启用
-o可将自动加载耗时从 ~8ms 降至 ~4ms - 叠加
-a后，进一步压到 ~2.5ms —— 这多出的 1.5ms 主要来自避免了对每个未命中 classmap 的类做 PSR-4 路径拼接 +file_exists()判断 - 若项目含大量未声明的运行时类（如通过
eval()、动态命名空间构造），-a会直接失败，而-o仍能兜底
所以性能提升不是线性叠加，而是“减少不确定性路径查找”的收益。它不加速已命中的类，只让“未命中”不再拖慢整体。
生产部署推荐组合：-a --no-dev，且应集成进 CI/CD
单独本地执行 composer dump-autoload -a --no-dev 是无效努力——它只刷新 autoload 文件，不保证 classmap 完整性。真正可靠的做法是：
- 在
composer.json中显式配置："config": { "optimize-autoloader": true, "classmap-authoritative": true } - CI/CD 构建阶段统一执行：
composer install --no-dev --optimize-autoloader
（该命令自动启用-a，无需再加参数） - 禁止在生产服务器上手动运行
dump-autoload：classmap 必须与当前代码快照严格一致，线上改代码再 dump 极易引发 classmap 过期
最容易被忽略的一点：即使启用了 -a，如果项目用了 include_once 或 require 手动加载非标准 PHP 文件（比如配置数组、函数库），这些文件不会进入 classmap，也不会被 -a 影响——它们本来就绕过了 Composer 自动加载机制。
