启用--optimize-autoloader可显著提升类加载速度，因其将所有可静态分析的类全部写入classmap，跳过PSR-4文件系统遍历，直接哈希查表；但仅对类名与文件名严格匹配、无动态加载的类生效，且需配合OPcache才能发挥最佳效果。
开启 --optimize-autoloader 能显著加快类加载速度，但只在生产环境（composer install --no-dev --optimize-autoloader）下生效，开发时用它反而可能掩盖自动加载问题。
为什么 --optimize-autoloader 能提速
默认情况下，Composer 使用「类映射 + PSR-4 回退」混合策略：先查 vendor/composer/autoload_classmap.php，没命中就按 PSR-4 规则层层扫描 src/ 目录。而启用该选项后，Composer 会把所有可静态分析的类（含 PSR-4 下能穷举的类）**全部写入 classmap**，跳过文件系统遍历和路径拼接，直接哈希查表。
关键点：
- 仅对「能被 Composer 静态发现」的类生效（即文件名与类名严格匹配、无动态注册、无条件加载）
- 不改变
autoload_files或autoload_psr4的行为，只是把它们“编译”进 classmap - 生成的
vendor/composer/autoload_classmap.php体积变大，但 PHP 解析一次后常驻 OPcache，实际开销极小
composer install 和 composer update 中的使用差异
两者都支持该参数，但语义不同：
-
composer install --optimize-autoloader：仅应用composer.lock中已记录的 classmap 优化结果，安全、可重复 -
composer update --optimize-autoloader：重新扫描所有包并生成新 classmap，适合升级依赖后重建优化，但可能因新包结构变化导致 classmap 增大或漏类 - CI/CD 流程中应固定用
install，避免update引入非预期变更
容易被忽略的兼容性陷阱
启用后，以下情况会失效或出错：
- 类文件名与类名不一致（如
FooBar.php里定义class Foo_bar），不会被收录进 classmap - 运行时动态 require 的文件（如
require __DIR__.'/config/'.env().'.php';）不受影响，但若其中定义了类，这些类不会被优化 - 某些插件（如
ocramius/package-versions）依赖未优化的 autoloader 行为，开启后可能报Class not found—— 此时需检查其文档是否声明兼容 optimized mode - PHP 7.4+ 开启
opcache.preload时，classmap 优化收益减弱，但仍有价值（preload 不处理所有 classmap 条目）
验证是否生效的实操方法
别只看命令是否成功，要确认结果：
grep -c '=>' vendor/composer/autoload_classmap.php
对比开启前后该数值：若从几百升至数千，说明优化已覆盖大量 PSR-4 类；若变化微小，可能是项目本身 classmap 已占主导，或 PSR-4 路径配置有误（如漏掉 src/ 后缀）。
线上部署后，还可通过 opcache_get_status()['opcache_statistics']['oom_restarts'] 辅助判断：若 OOM 重启减少，说明 classmap 查找更轻量，内存压力下降。
真正起作用的是 classmap 文件内容是否完整、OPcache 是否成功缓存它，而不是命令有没有加参数。
