根本原因是未组合使用 --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 映射或改用其他机制——这点不提前验证，上线就炸。
