开启 optimize-autoloader 仅在 composer install/update 时生成 classmap 文件才生效，dump-autoload -o 无效；需搭配 --no-dev 用于生产环境，且 --classmap-authoritative 会禁用目录扫描、风险更高。
开启 optimize-autoloader 能显著提升生产环境的类加载速度，但必须配合 composer install --no-dev 使用，否则优化无效甚至引发问题。
为什么 optimize-autoloader 开了却没效果？
常见现象是加了配置、跑了 composer dump-autoload，但 class_exists() 或自动加载耗时几乎不变。根本原因是：该选项只在生成 vendor/autoload_classmap.php 时起作用，而这个文件仅由 composer install（或 update）触发，dump-autoload 默认不重建类映射表。
-
composer install --optimize-autoloader✅ 正确：安装依赖 + 生成 classmap -
composer install -o✅ 等价写法，更常用 -
composer dump-autoload -o❌ 无效：不重建 vendor 下的 classmap 文件 - 单独在
composer.json里设"optimize-autoloader": true❌ 不触发，只是默认开关
optimize-autoloader 和 --classmap-authoritative 的区别
两者都为提速，但机制和风险不同：
-
--optimize-autoloader（或-o）：生成完整 classmap，并让 autoloader 优先查表；未命中时仍 fallback 到 PSR-4/PSR-0 规则扫描目录 —— 安全，推荐用于大多数项目 -
--classmap-authoritative（或-a）：生成 classmap 后，**彻底禁用目录扫描**；类必须出现在 classmap 中，否则直接报错Class not found—— 快，但要求所有类都已纳入 autoload 配置，CI/部署中容易漏掉新文件 - 二者可共用：
composer install -oa，但需确认代码无动态 require 或未声明的类文件
哪些场景下不该开 optimize-autoloader？
开发阶段频繁改类名、增删文件时，开启反而增加维护成本：
- 每次新增类后，必须重新跑
composer install -o（或update），否则新类无法被加载 - Docker 多阶段构建中，若 build 阶段用了
-o，但 runtime 阶段挂载了新代码，会因 classmap 过期导致 500 - Laravel 的
app/Providers/下某些运行时注册的类，若未被静态扫描到，可能在-a模式下失败 - 依赖包含大量条件加载（如通过
function_exists()判断后require），classmap 无法覆盖这类逻辑
真正要留意的是：classmap 一旦生成，就和源码结构强绑定。上线前务必验证 vendor/autoload_classmap.php 是否包含关键类，而不是只看命令有没有加 -o。
