开启 optimize-autoloader 能提升类加载速度，适用于依赖多且只用部分类、无稳定 opcache 的生产环境；需通过 composer install --optimize-autoloader --no-dev 启用，并验证 autoload_classmap.php 是否生成。
开启 optimize-autoloader 能显著加快生产环境的类加载速度，但它不是默认开启的，也不能在开发中盲目启用。
什么时候该用 optimize-autoloader
它只在生成“类映射表”（classmap）时起作用，适用于以下场景：
- 项目依赖大量 PSR-0/PSR-4 包，且实际运行时只用到其中一部分类 —— 开启后 Composer 会把所有已知类路径预生成进
vendor/composer/autoload_classmap.php，跳过文件系统遍历 - 部署到无 opcache 或 opcache 不稳定（如某些共享主机）的环境，需要靠 classmap 缓存兜底
- 你确认不会频繁修改
autoload配置或新增未声明的类文件（比如运行时动态生成类）
optimize-autoloader 怎么开、怎么验
最常用的是安装/更新时加参数，而不是改配置文件：
- 全局生效（推荐）：
composer install --optimize-autoloader --no-dev（生产部署标准命令） - 仅本次更新生效：
composer update --optimize-autoloader - 写进
composer.json的"config"里也行，但容易被忽略或误传到开发环境：{"config": {"optimize-autoloader": true}} - 验证是否生效：检查
vendor/composer/autoload_classmap.php文件是否存在且非空；再看vendor/composer/autoload_real.php中是否调用了$loader->addClassMap(...)
开了之后为什么反而报错或找不到类
常见原因都和“预生成”机制有关：
- 类文件在
autoload配置里没声明，又不在 PSR-4/PSR-0 标准路径下 —— classmap 不会收录，运行时报Class not found - 用了
files类型自动加载（比如全局函数），但--optimize-autoloader不处理这类条目 —— 函数仍能加载，但 classmap 里没有记录，容易误判为“没生效” - 开发中频繁改类名或移动文件，但忘了重新运行
composer dump-autoload --optimize-autoloader—— classmap 还是旧的，导致加载错位 - 某些插件或脚本（如 Laravel Octane、Swoole 热重载）依赖实时扫描，开了优化后可能跳过新类 —— 不是 bug，是设计使然
性能提升有，但别高估它的作用
classmap 加载确实比 PSR-4 的 file_exists() + require 快，但真实收益取决于你的应用结构：
- 小项目（
- 一旦启用 opcache（PHP >=7.4 默认全启用），classmap 和 PSR-4 的差距进一步缩小 —— opcache 已缓存了文件路径和 opcode，此时 classmap 主要省的是首次 stat 开销
- 它不压缩体积、不减少内存占用、也不影响 autoloader 的逻辑行为，只是换了一种查表方式
真正卡顿的地方，往往在数据库连接、HTTP 请求或模板渲染，而不是自动加载本身。别为了一个 flag 过度优化。
