生产环境必须用 composer install --no-dev --optimize-autoloader --classmap-authoritative，因为 dump-autoload -o 在 Composer 2+ 中不触发 classmap 全量扫描，仅刷新 PSR-4 映射；只有 install/update 才生成完整 autoload_classmap.php，且 --classmap-authoritative 强制关闭 fallback，杜绝 stat() 调用，确保性能稳定。
生产环境必须用 composer install --no-dev --optimize-autoloader --classmap-authoritative，其他组合基本无效或白忙活。
为什么不能只跑 composer dump-autoload -o
这个命令在 Composer 2+ 中默认不生成或更新 autoload_classmap.php，它只刷新 PSR-4 映射逻辑，不扫描类文件。你执行完后打开 vendor/composer/autoload_classmap.php，大概率是空数组或只有 vendor 包条目——说明 classmap 根本没建起来。真正触发 classmap 全量扫描的，是 install 或 update 过程，不是 dump-autoload。
-
dump-autoload -o只对项目里显式配置了"classmap": ["src/"]的情况才有效 - 纯 PSR-4 项目（如 Laravel 默认结构）跑
-o几乎不产出 classmap 条目 - CI/CD 脚本里写错成
dump-autoload -o，部署后性能毫无变化，是最常见的翻车点
--classmap-authoritative 不是可选项，是强制项
加了 --optimize-autoloader 但没加 --classmap-authoritative（或简写 -a），autoloader 仍会 fallback 到 PSR-4 路径拼接和 file_exists() 检查——这反而比不优化还多一次系统调用。权威模式的意思是：“表里没有，就别找了，直接报错”。它让加载路径彻底脱离文件系统，性能才真正稳定。
- 必须配合
--no-dev：dev 包里的类不会进 classmap，残留它们会导致 fallback 触发 - 新增类后必须重新
install，否则Class not found是预期行为，不是 bug - 验证是否生效：
strace -e trace=stat php -r "new AppModelsPost();"应该看不到任何stat("/path/to/src/Models/Post.php")调用
autoload 配置本身容易拖慢优化效果
再快的 classmap 也救不了冗余的 autoload 声明。Composer 会按注册顺序逐个匹配 PSR-4 前缀，前缀越多、越细、越重叠，运行时字符串比对和 fallback 尝试就越频繁。
- 把
"App\Http\Controllers": "app/Http/Controllers/"和"App\Http\Middleware": "app/Http/Middleware/"合并为"App\Http": "app/Http/" - 删掉测试目录、文档路径、空目录等无用映射（如
"tests/": "tests/"） - 避免多个前缀指向同一物理路径（如
"App": "src/"和"App\Services": "src/"），这会让查找逻辑多走一轮
OPcache 和 classmap 的关系常被误判
classmap 数组本身是 PHP 数组，每次请求都要反序列化或 require 进内存。一个中型项目 classmap 文件可能达 2–5 MB，全量加载反而拖慢首字节时间。真正的性能拐点在 OPcache 是否启用并预热。
- 确认
opcache.enable=1且opcache.preload已配置（PHP 7.4+） -
opcache.save_comments=0能减小预编译体积，间接提升 autoload 加载速度 - 不要迷信 APCu 缓存 classmap 查找结果——APCu 缓存的是 key-value，而 classmap 是数组查找，O(1) 本身已足够快；瓶颈通常在 OPcache 是否命中
最易被忽略的一点：vendor/autoload.php 必须被直接引入，而不是被封装在自定义引导文件里绕过——否则所有优化都失效。
