Composer 的 --classmap-authoritative 才能彻底移除 PSR-4 回退逻辑，而 --no-dev --optimize-autoloader 仅优化未根除；需确保无 autoload-dev PSR-4、检查 autoload_real.php 无 prefixesPsr4、精简 classmap 路径并启用 opcache。
为什么composer install --no-dev --optimize-autoloader还不够
它确实跳过了 require-dev 包，也生成了 PSR-4 静态映射，但没切断所有回退路径。只要 autoload_real.php 里还保留着 foreach ($this->prefixesPsr4 as ...) 分支，每次类加载就仍会触发字符串前缀匹配、目录拼接和 file_exists() 调用——哪怕最终走的是 classmap 分支，这些逻辑仍被解析执行。
真正要砍掉这部分开销，必须让 autoloader 完全不加载 PSR-4 查找逻辑：
- 确认
composer.json中未定义"autoload-dev"的 PSR-4 规则（否则即使加--no-dev，其前缀也可能被误扫进主映射） - 部署命令必须带
--classmap-authoritative，它会让findFile()方法只剩if ($classMap = $this->classMap)这一条路径 - 检查
vendor/composer/autoload_real.php：如果看到$this->prefixesPsr4或$this->fallbackDirsPsr4相关代码，说明权威模式根本没生效
classmap-authoritative 开启后 Class not found 怎么快速定位
报错不是配置错了，是 classmap 漏掉了某个类。常见漏点不在你写的代码里，而在依赖包或加载方式上：
-
symfony/polyfill类库大量使用条件加载（如if (PHP_VERSION_ID ），这类文件不会被 classmap 扫描到，开了--classmap-authoritative就直接挂 -
"files": ["app/Helpers/functions.php"]引入的全局函数没问题，但若该文件里new SomeDynamicClass()，而SomeDynamicClass不在 classmap 中，就会失败 - Laravel 的
AppServiceProvider::boot()里动态绑定的类（如$this->app->bind('foo', function () { return new Foo(); });）不对应物理文件，自然不在 classmap 里——这不属于 autoload 覆盖范围，跟权威模式无关 - 检查
vendor/composer/autoload_classmap.php是否真包含目标类名：搜索"Your\Full\Class\Name"，没有就说明扫描阶段漏了
autoload_classmap 文件越大，性能反而越差？
是的。autoload_classmap.php 是一个 PHP 数组字面量，每次请求都会被 require 并反序列化（或由 opcache 编译缓存）。如果项目用了 "classmap": ["src/", "tests/", "docs/"]，那 docs/ 下的 Markdown 或 README 文件也会被扫描进 classmap（Composer 会尝试解析所有 .php 文件），导致数组体积暴涨数 MB，而实际请求只用其中不到 5% 的条目。
精简策略很简单：
- 删掉
composer.json中所有非必要 classmap 路径，尤其是tests/、docs/、examples/ - PSR-4 前缀尽量合并：把
"App\Http\Controllers\": "app/Http/Controllers/"和"App\Http\Middleware\": "app/Http/Middleware/"合并为"App\Http\": "app/Http/" - 避免通配符式写法（如
"MyLib\*": "src/"），Composer 会忽略，且易引发歧义
opcache.preload 能替代 classmap 优化吗
不能替代，但能绕过。preload 在 PHP-FPM master 进程启动时就把指定类文件 require_once 进内存并编译，后续 worker 进程直接复用，完全跳过 Composer autoloader 的任何逻辑。
但它有硬限制，容易翻车：
- preload 脚本里禁止任何运行时判断：
class_exists()、function_exists()、new实例化、include_once全都不行，只能用纯require或include - 不要 preload 整个
vendor/，而是精确列出高频类：比如IlluminateFoundationApplication、核心 DTO、基础 Service 类 - preload 失败会导致整个 FPM 启动失败，日志里只显示
Failed to preload，必须配合opcache.error_log查具体哪行出错 - 它对 CLI 命令无效（如
php artisan tinker），所以不能指望它解决所有场景
最常被忽略的一点：所有这些优化都建立在 opcache.enable=1 且 opcache.save_comments=0 的基础上。没开 opcache，classmap 再小，每次请求也要重新 parse PHP 文件。
