composer如何避免autoload性能下降？（classmap-authoritative启用条件）

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 'XYZ' 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 多做一层路径校验和部署控制。