-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 自动加载机制。