optimize-autoloader 优化了类加载路径查找过程，将每次 new 或 class_exists() 时的文件系统遍历和 file_exists() 检查，替换为一次内存中的类名→路径映射表查询。
optimize-autoloader 到底优化了什么？
它把每次 new 或 class_exists() 时的“猜路径 + 检查文件是否存在”过程，换成一次内存查表——生成一张完整的 类名 → 文件路径 映射表（即 vendor/composer/autoload_classmap.php），彻底跳过目录遍历和 file_exists() 调用。
默认 PSR-4 加载逻辑：看到 App\Controllers\HomeController，就拼出 src/Controllers/HomeController.php，再检查这个文件存不存在。而启用 --optimize-autoloader（简写 -o）后，直接从预建数组里取值：
['App\\Controllers\\HomeController' => 'src/Controllers/HomeController.php']
- 对含大量短命名空间（如
Foo_Bar_Baz）、legacy classmap 库（如旧版 PhpExcel）、或分散在多层目录的类，提速最明显 - 纯 PSR-4 项目（如
App\\* → src/严格一一对应）提升有限，甚至因 classmap 文件变大而略微拖慢首次require - 它不改变你写的
autoload配置，只改变 Composer 怎么执行加载
什么时候该加 -o？命令怎么写才对？
生产环境部署必须加；本地开发一般不加——因为 classmap 是构建时快照，不是实时监听器。新增一个类却忘了 dump-autoload -o，就会报 Class not found，且无提示哪步漏了。
- CI/CD 打包或 Docker 构建时：
composer install --no-dev --optimize-autoloader
- 已有项目上线前补优化（不重装包）：
composer dump-autoload -o
- 想让所有项目默认生效（全局配置）：
composer config --global optimize-autoloader true
-
composer.json里的"optimize-autoloader": true不起作用——它只对dump-autoload命令生效，且仍需显式传参或配合全局配置
--classmap-authoritative 和 -o 是什么关系？能一起用吗？
--classmap-authoritative 是比 -o 更激进的开关：它告诉自动加载器“autoload_classmap.php 就是全部，别再 fallback 到 PSR-4 目录扫描了”。两者常组合使用，但风险也叠加。
- 组合效果：加载速度再快 10%~20%，尤其在高并发下减少 I/O 竞争
- 典型翻车场景：
Tests\\*类（如 Laravel 的 Feature 测试）被排除在 classmap 外，启用后直接无法加载；动态生成类（如某些 Mock 工具、AOP 库）也会失效 - 安全用法：
composer dump-autoload -o --classmap-authoritative
仅用于确认项目不含任何动态类发现逻辑的生产镜像 - 验证是否生效：看
vendor/composer/autoload_static.php中是否有'classMapAuthoritative' => true
为什么有时候加了 -o 反而更慢或报错？
不是参数有问题，而是环境没对齐。常见三类问题：
-
开发中误用：改了
app/Models/User.php却没运行composer dump-autoload -o，新类永远加载不到 -
测试环境冲突：Laravel Dusk、Pest 或自定义
autoload-dev下的类未被纳入 classmap，又开了--classmap-authoritative，测试直接崩 -
老旧包不兼容：某些 legacy 包依赖
autoload.files或__autoload回调，-o会禁用兜底逻辑，导致类找不到
排查建议：临时去掉 -o 运行一次，对比 vendor/composer/autoload_classmap.php 是否缺失关键类；再检查该类是否在 composer.json 的 autoload 或 autoload-dev 中正确定义。
真正要记住的不是“怎么开”，而是“谁负责在什么时候重新生成”——这往往才是线上类加载失败的真正源头。
