应在线上部署且类声明无误时使用--optimize-autoloader，它将PSR映射固化为classmap提升性能；开发环境禁用，以免掩盖问题或导致新增类加载失败。
加了 --optimize-autoloader 确实能提速，但只在生产环境生效，开发时反而可能掩盖类未声明问题。
什么时候该用 --optimize-autoloader
这个参数本质是让 Composer 把 PSR-4/PSR-0 映射关系“固化”成一个扁平的 classmap 数组，跳过运行时路径解析。适合：
- 部署到线上服务器后，不再频繁增删类文件
- 项目依赖大量小包（如 Laravel 的 vendor 里几百个包），autoload 阶段耗时明显
- 你已确认所有类都正确声明了命名空间和文件路径（否则优化后报错更难定位）
composer install 和 composer update 都要加参数
只对当前命令生效，不会写入配置。漏掉任意一次，生成的 vendor/autoload.php 就没优化：
composer install --optimize-autoloader --no-dev composer update --optimize-autoloader --no-dev
注意：--no-dev 常和它一起用，因为 dev 依赖不参与生产自动加载，去掉能进一步缩小 classmap 体积。
为什么开发环境通常不该开？
开启后，Composer 不再实时扫描 PSR-4 目录结构，而是依赖生成的 vendor/composer/autoload_classmap.php。后果包括：
- 新增一个类文件后，
composer dump-autoload必须手动执行，否则自动加载失败 - 改了
composer.json里的autoload配置，不会自动重生效 - 某些 IDE 或调试工具依赖动态路径推导，可能失效
开发阶段建议保持默认行为，靠 opcache 缓存已足够快。
还有更快的：启用 classmap-authoritative
这是更激进的优化，在 composer.json 里配置：
{
"config": {
"classmap-authoritative": true
}
}
效果是：Composer 完全忽略 PSR-4 自动发现逻辑，只查 classmap。比 --optimize-autoloader 更快，但也更脆弱——任何没被 classmap 覆盖的类（比如运行时生成的代理类）会直接报 Class not found。
真正需要极致 autoload 性能的 CLI 工具或高并发服务才考虑它，Web 请求中多数情况没必要。
