--optimize-autoloader 仅对 PSR-4/classmap 可静态分析的类生效，跳过动态类名、eval、条件加载等文件；需配合 --classmap-authoritative 才能彻底禁用文件查找，否则性能提升有限（5%–15%）。
为什么 composer install --optimize-autoloader 有时没效果
根本原因不是命令没跑，而是自动加载优化只对 classmap 类型生效，且仅当你的代码满足“可静态分析”条件时才真正提速。PSR-4 自动加载本身不参与此优化，--optimize-autoloader 实际是把所有 PSR-4 映射路径下的类文件扫描一遍，生成扁平的 classmap 数组，绕过路径拼接和文件存在性检查。
常见错误现象：composer install --optimize-autoloader 执行后 vendor/autoload.php 体积变大，但请求耗时几乎不变——大概率因为你项目里大量使用了动态类名（如 $class = $prefix . $name; new $class();），或类文件里有 eval()、条件加载逻辑，Composer 在构建 classmap 时直接跳过了这些文件。
- 只有
.php文件且文件名与类名严格匹配（如Foo.php含class Foo）才会被收录进优化后的 classmap - 含匿名类、动态 trait 引入、
class_alias()的文件通常被忽略 - 如果
composer.json中"autoload"没配psr-4或classmap，该参数完全不触发任何优化
optimize-autoloader 和 classmap-authoritative 的区别与共用场景
前者是“尽力而为”：扫描所有 autoload 路径，生成尽可能全的 classmap；后者是“强制信任”：运行时完全忽略 PSR-4/PSR-0 的文件查找逻辑，只查 classmap——哪怕某个类实际存在、只是没被扫进去，也会直接抛出 Class not found 错误。
典型使用场景是部署到无写权限的生产环境，或配合 Docker 多阶段构建，在 build 阶段固定类映射。
- 单独用
--optimize-autoloader：安全，兼容性强，适合大多数 CI/CD 流程 - 加
--classmap-authoritative：性能略高（省掉 file_exists 检查），但要求你 100% 确认所有类都能被静态发现，否则上线就报错 - 二者可同时启用：
composer install --optimize-autoloader --classmap-authoritative - 注意：Laravel 的
app/Providers/AppServiceProvider.php若用了class_exists('SomeDynamicClass')，开启--classmap-authoritative后可能意外失败
如何验证优化是否生效及真实收益
别只看 vendor/composer/autoload_classmap.php 文件大小，重点查两件事：是否生成了 classmap、运行时是否真走了 classmap 分支。
实操建议：
- 执行后检查
vendor/composer/autoload_classmap.php是否非空，且内容包含你项目里的类（如'App\Models\User' => __DIR__ . '/../app/Models/User.php'） - 在代码中临时加一句
var_dump(ComposerAutoloadClassLoader::getRegisteredLoaders());，确认classMap数组长度明显大于 0 - 用
xdebug或blackfire抓一次请求，看ComposerAutoloadClassLoader::findFile()方法调用次数：优化前它会反复尝试拼路径+file_exists()，优化后应大幅减少 - 真实收益一般在 5%–15% 的 autoloading 时间下降，对 I/O 敏感环境（如 NFS 卷、低配云主机）更明显；纯内存环境提升有限
CI/CD 中该不该默认开启 --optimize-autoloader
应该，但得配合正确的缓存策略。问题不在命令本身，而在很多团队把它和 composer install 一起放在每次构建的中间步骤，却没清理旧 vendor —— 导致 classmap 反复叠加、体积膨胀、甚至混入已删除类的路径。
- 推荐做法：在 CI 中固定用
composer install --no-dev --optimize-autoloader --prefer-dist，且确保vendor/不被缓存或每次 clean - 禁止在本地开发时全局 alias 成
composer install加该参数，因为开发中频繁增删类，classmap 容易过期，反而引发奇怪的Class not found - Docker 构建中，把它放在
COPY composer.json composer.lock ./之后、COPY . .之前，避免把未提交的类文件漏进 classmap - 如果你用的是 Laravel Octane 或 Swoole，这个参数几乎必开，否则每个 worker 进程都会重复做路径解析
最常被忽略的一点：优化只作用于 Composer 管理的 autoload，不碰 include/require 手动引入、也不加速框架自身的门面（Facade）解析逻辑。别指望它解决所有加载慢问题。
