加了--optimize反而更慢，是因为它生成的autoload_classmap.php需全量加载，而单次请求仅用不到5%的类；Composer 2默认的autoload_static.php更轻量、OPcache友好。
为什么加了 --optimize 反而更慢？
PHP 7.4+ 和 Composer 2.x 环境下，composer dump-autoload --optimize（即 -o）生成的 autoload_classmap.php 是一个全量数组，每次请求都要完整反序列化或 require 进内存。而实际单次请求只用到其中不到 5% 的类——相当于为查一个电话号码，硬把整本黄页背下来。
真正起效的是 Composer 2 默认生成的 autoload_static.php：它是预编译的静态映射表，结构紧凑、OPcache 友好。加 -o 不仅不提速，还可能让冷启动变慢。
- 检查
vendor/composer/目录下是否存在autoload_classmap.php且体积达数 MB —— 这是冗余优化的典型信号 - 确认是否启用了 OPcache：
opcache.enable=1且opcache.validate_timestamps=0（生产环境必须关时间戳校验） - 删掉
composer.json中无用的 autoload 条目，比如"docs/": ["docs/"]或"tests/": ["tests/"]，它们会让 classmap 扫描白费力气
--classmap-authoritative 什么时候能开？
这个参数不是“开了就快”，而是强制 autoloader 查不到类就直接报错，不再 fallback 到 PSR-4 路径拼接。它只在所有条件都满足时才安全：
- 项目中没有
"files"类型自动加载（例如全局函数文件） - 没用
classmap扫描插件目录、模板逻辑等非标准路径 -
autoload-dev块已彻底排除（部署必须带--no-dev） - 所有类名与路径严格符合 PSR-4：命名空间末尾有反斜杠、目录大小写完全一致、
App\Http\Controllers\对应app/Http/Controllers/
漏掉任意一条，就会出现 Class not found，但错误堆栈不指向真实问题（比如拼写错误），而是静默失败。
OPcache 预加载（opcache.preload）怎么配才不崩？
别指望 composer dump-autoload 支持 --apcu 或 --preload —— 它根本不参与 PHP 编译阶段。真正的预加载靠 opcache.preload 指向一个 PHP 脚本，该脚本需显式 require_once 所有核心类文件。
关键限制很硬：
-
preload.php中不能有动态类名、eval()、未定义函数调用 - 不能 include 或 require
vendor/autoload.php—— 它内部有PHP_SAPI判断和spl_autoload_register注册，这些在 preload 阶段被禁止 - 必须先运行
composer dump-autoload -o -a生成可靠的autoload_classmap.php，再遍历它写 preload 脚本 -
opcache.enable_cli=1必须开启，否则composer命令生成的文件无法被 OPcache 缓存
验证优化是否真生效了
光看命令没报错不等于成功。最直接的验证方式是检查生成文件和运行时行为：
- 对比
vendor/composer/autoload_classmap.php大小：优化后应明显增大（含所有类路径），若只有几十行或为空，说明--no-dev没生效或autoload-dev被意外合并 - 用
opcache_get_status()['scripts']查看关键文件（如vendor/composer/autoload_static.php）是否在缓存中且hits持续增长 - 部署新版本后必须清空 OPcache（
opcache_reset()或重启 PHP-FPM），否则旧缓存会继续服务，掩盖配置变更效果
最容易被忽略的是 opcache.enable_cli=1 和 opcache.revalidate_freq=0 的组合 —— 前者影响 composer 命令输出能否进缓存，后者决定缓存是否真的“永不校验”。缺一不可。
