根本原因是未组合使用 --optimize --no-dev --classmap-authoritative：--optimize 生成 classmap，--no-dev 减少条目，--classmap-authoritative 禁用文件系统 fallback，三者缺一不可；

加 --apcu 可进一步缓存 classmap 到共享内存。

为什么 composer dump-autoload 生成的 autoloader 在生产环境变慢？

根本原因不是命令本身慢，而是默认生成的 autoloader 包含大量冗余逻辑：它保留了开发期需要的类映射（如 PSR-0/PSR-4 混合路径、未优化的文件扫描）、未禁用自动加载失败时的 fallback 机制，并且不强制使用 classmap 查找——这些在生产环境毫无必要，反而增加每次 class_exists() 或 new 实例时的路径判断开销。

composer dump-autoload --optimize --no-dev --classmap-authoritative 三个参数必须一起用

单独用任一参数效果有限，组合才是关键：

• --optimize：生成 vendor/composer/autoload_classmap.php，把所有类名直接映射到文件路径，跳过 PSR-4 前缀匹配；但若没配合其他参数，仍会 fallback 到扫描目录
• --no-dev：彻底排除 require-dev 中的包及其 autoloading 配置，减少 classmap 条目约 30–60%（视项目而定）
• --classmap-authoritative：告诉 autoloader「classmap 就是全部，别再尝试文件系统查找」——这是性能跃升的核心，能避免每次 autoload 失败后遍历 vendor/ 下数十个目录

生产部署脚本里漏掉 --apcu 就浪费了 20%+ 性能提升

PHP 7.0+ 环境下，APCu 扩展开启后，composer dump-autoload --apcu 会把 classmap 缓存到共享内存。注意两点：

• 必须确保 PHP-FPM 进程能访问同一块 APCu 缓存（即未启用 apc.enable_cli=1 但 CLI 和 FPM 共享 apc.shm_size）
• --apcu 仅作用于 classmap 模式，所以必须和 --optimize --classmap-authoritative 同时使用，否则无效
• 若部署时用的是容器或无状态实例，记得在构建阶段运行该命令，而非每次启动时重复执行

CI/CD 中误用 composer install --no-dev 会导致 autoloader 未优化

composer install --no-dev 不等于 dump-autoload 优化。它只跳过 dev 包安装，但 autoloader 仍按 composer.json 中原始配置生成（可能含 PSR-0、未压缩的命名空间映射）。正确做法是：

• CI 流水线中，在 composer install --no-dev 后显式追加：
  

  composer dump-autoload --optimize --no-dev --classmap-authoritative --apcu

• 检查生成结果：确认 vendor/composer/autoload_classmap.php 文件存在且大小明显大于未优化版本（通常 >500KB），且 vendor/composer/autoload_static.php 中 $classMap 数组非空、$fallbackDirsPsr4 为空数组
• 上线前用 php -r "var_dump(class_exists('SomeClass'));" 快速验证是否仍触发文件系统访问（配合 strace -e trace=openat php ... 可观察）

最常被忽略的是 --classmap-authoritative 的前提条件：一旦启用，任何未被 classmap 覆盖的类（比如运行时生成的代理类、测试桩、某些 AOP 工具注入的类）将直接报 Class not found。如果项目用了 Laravel Telescope、Mockery、ProxyManager 等动态类生成工具，得单独为它们保留 PSR-4 映射或改用其他机制——这点不提前验证，上线就炸。