composer dump-autoload -o 在 PHP 7.4+ 和 Composer 2.x 中不提速反降速，因生成大体积 autoload_classmap.php 导致冷启动更慢、内存占用翻倍；真正生效的优化是 composer install --optimize-autoloader。
composer dump-autoload -o 在 PHP 7.4+ 和 Composer 2.x 中基本不提速
加 -o 后生成的 autoload_classmap.php 是一个全量数组，常达数 MB。PHP 每次请求都要完整加载并反序列化它，而实际只用到其中不到 5% 的类。在 OPcache 已启用的前提下，autoload_static.php（Composer 2 默认生成）已被高效缓存，而 classmap 因结构动态、体积大，难以被有效缓存——结果是冷启动更慢，热请求无明显收益。
常见错误现象：composer dump-autoload -o 执行后，strace 显示大量 stat() 调用消失，但整体响应时间反而上升；memory_get_peak_usage() 显示 autoload 阶段内存占用翻倍。
- Composer 2.x 中
-o已被标记为冗余操作，等价于--classmap-authoritative，但不等价于“更快” - 若项目含
"files"类型 autoload（如全局 helper 函数），-o仍会将其写入 classmap，但不会去重，重复require可能触发Fatal error: Cannot redeclare - 本地开发中长期开启
--optimize-autoloader容易掩盖命名空间拼写或路径配置错误，调试时更难定位真实问题
真正生效的优化命令是 composer install --optimize-autoloader
composer dump-autoload -o 不重建 vendor/composer/autoload_classmap.php，只是“假装优化”；它只刷新映射，不重建 classmap。真正重建 classmap 并让生产环境自动加载变快的，是 composer install --optimize-autoloader（或简写为 composer install -o）。
这个命令会：重新扫描所有 autoload 配置项（包括 PSR-4、classmap、files），生成完整 classmap，并跳过 vendor 缓存逻辑，确保映射与当前代码严格一致。
- CI/CD 部署脚本中必须写死：
composer install --no-dev --optimize-autoloader -
"optimize-autoloader": true写在composer.json里不会自动触发任何动作，它只是个默认开关，不解决实际问题 - 如果新增了
app/Console/Commands/DeployCommand.php，但命名空间写成namespace AppConsoleCommands;（缺反斜杠），而composer.json中配置的是"App\": "app/"，那么 classmap 扫描失败，该类不会进入映射——报错不是配置错了，而是 classmap 漏了类
--classmap-authoritative 不是“加了就快”，而是“加了就严格”
--classmap-authoritative 的作用不是提速，而是关掉 fallback：查不到 classmap 就直接报 Class not found，不再尝试按 PSR-4 规则拼路径。它只在满足全部条件时才安全：
- 项目中没有
"files"类型 autoload（否则这些函数文件不会被 classmap 覆盖，运行时报 undefined function） - 没用
classmap扫描插件目录、模板逻辑等非标准路径 -
autoload-dev未被合并进主 autoload（部署时必须加--no-dev） - 所有类名与文件路径严格符合 PSR-4：大小写一致、命名空间末尾有反斜杠、目录结构与命名空间完全对应
漏掉任意一条，--classmap-authoritative 就会让错误变得隐蔽：不是报“类名拼错”，而是直接 Class not found，且堆栈不指向真实出错点。
APCu autoloader 在 CLI 下基本白干
composer install --apcu-autoloader 只在 PHP-FPM 环境下真正起效。APCu 的 user cache 在 CLI 进程退出后即销毁，无法跨请求共享，所以你在本地跑 php artisan tinker 或部署脚本里执行它，几乎不产生任何性能收益。
如果你在容器化部署中反复 composer install 却没清理旧 vendor/，可能残留多个版本的 autoload_classmap.php，被重复加载——这是 CI 构建缓存污染的典型表现。
真正值得投入的优化点，其实是精简 PSR-4 前缀：删掉测试目录、文档路径、废弃模块的 autoload 配置；避免重叠前缀（如同时注册 "App\": "app/" 和 "AppConsole\": "app/Console/"），因为 Composer 会逐个比对，每多一个前缀就多一次字符串匹配和 stat() 调用。
