classmap-authoritative 能提速是因为跳过PSR-4/PSR-0扫描，仅依赖O(1)数组查找；但要求所有类均被classmap覆盖，否则直接报Class not found。
classmap-authoritative 为什么能提速 autoload
开启 classmap-authoritative 后，Composer 会完全跳过 PSR-4/PSR-0 的文件扫描逻辑，只从生成的 vendor/composer/autoload_classmap.php 中查类名。这意味着：没有 file_exists()、没有 is_dir()、没有递归遍历 src/ 或 lib/ —— 每次 new Foo() 都是纯数组查找，O(1)。
但它不是“开就完事”，前提是你的项目里所有类都得被 classmap 覆盖住，否则会直接 Class not found。
启用前必须确认的三件事
否则一上线就报错，而且错误不提示“你漏了 classmap”，只报 Class 'X\Y\Z' not found：
-
composer.json中的"autoload"和"autoload-dev"里，所有路径（如"src/"、"tests/"）必须存在且可读，不能有拼写错误或权限问题 - 所有类必须通过
composer dump-autoload --classmap-authoritative扫描进 classmap —— 它不会扫描vendor/下已安装包的源码（那是它们自己的 autoload 规则），只扫你项目目录 +autoload-files列表 - 动态加载的类（比如用
eval()、include_once("runtime_{$name}.php")生成的类）不会进 classmap，这类代码必须改掉或移出 autoload 路径
生产环境启用的正确姿势
别在本地开发时开，也别在 CI 里默认加 —— 它会让 composer install 变慢（因为要全量扫描），而且掩盖路径配置错误：
- 只在部署脚本中显式执行：
composer install --no-dev --optimize-autoloader --classmap-authoritative - 确保
vendor/是干净重建的（不要复用 dev 环境的 vendor），否则 classmap 文件可能残留旧路径 - 验证是否生效：检查生成的
vendor/composer/autoload_static.php中$classMap数组长度是否合理（比如几千行），再 grep 一个你确定存在的类名，看是否在其中
常见误判：autoload 性能差 ≠ 该开 classmap-authoritative
很多情况开它反而更糟或无效：
- 项目大量使用
class_alias()或运行时注册类（如 Laravel 的App::bind()），这些类不在 classmap 里，开了就挂 - 依赖的第三方包用了
files类型 autoload（如"autoload": { "files": ["src/helpers.php"] }），这些文件仍会被 require_once，但 classmap 不管它们 —— 开了没收益，还增加 dump 成本 - 服务器开了 OPcache 且配置合理（
opcache.enable=1、opcache.validate_timestamps=0），那 PSR-4 的性能瓶颈其实在磁盘 IO，而不是 PHP 解析；这时开 classmap-authoritative 收益有限，但维护成本上升
真正卡在 autoload 的，往往是那些没开 OPcache、又频繁 new 大量小类的 CLI 命令或微服务入口 —— 这类场景才值得为 classmap-authoritative 多做一层路径校验和部署控制。
