optimize-autoloader 是让 Composer 生成扁平 classmap 以跳过 PSR 自动查找、减少 stat() 调用的生产优化选项，须配合 --no-dev 和 --classmap-authoritative 使用才生效。
optimize-autoloader 是什么，为什么生产环境要用它
它不是“加速 autoload”本身，而是让 Composer 生成更扁平、更少文件 I/O 的 autoload_classmap.php，跳过 PSR-4/PSR-0 的路径扫描逻辑。生产环境没开发时的类变动需求，关掉动态查找能省下大量 stat() 系统调用——尤其在 NFS 或容器挂载卷上，效果明显。
关键点：optimize-autoloader 必须配合 --no-dev 使用才真正生效；否则 dev 依赖的 autoload 规则仍会保留，classmap 里混入大量测试类，反而拖慢加载。
怎么正确启用 optimize-autoloader
部署时执行这条命令才是标准姿势：
composer install --no-dev --optimize-autoloader --classmap-authoritative
--classmap-authoritative 是配套关键参数：它告诉 Autoloader “只信 classmap，别 fallback 到 PSR 查找”，彻底堵死动态扫描路径。两者合用，才能把 autoload 性能压到最低开销。
- 别用
composer dump-autoload --optimize替代 —— 它不清理 dev 依赖，也不强制 classmap 权威模式 - CI/CD 中若分两步（先
install再dump-autoload），第二步会覆盖第一步的优化，直接失效 - Docker 构建时，确保
vendor/是在 final stage 里通过composer install生成的，而不是从 build stage 复制过来——复制会丢失生成的 classmap 文件
常见错误现象和排查方法
启用了却没提速？大概率是这些原因：
- 代码里用了
class_exists('SomeClass', false)且该类不在 classmap 中 →--classmap-authoritative下直接返回 false，行为改变 - 某些包（如 Laravel 的部分 facade）依赖运行时类发现，关闭动态查找后报
Class not found -
composer.json里写了"autoload": {"files": ["src/helpers.php"]}，但没加--apcu-autoloader或手动 require，导致 helpers 没加载 - 部署后没清 opcache → 即使 classmap 更新了，PHP 还在用旧的 opcode 缓存，需调用
opcache_reset()或重启 fpm
要不要加 --apcu-autoloader
如果 PHP 启用了 APCu 扩展（>=7.4 推荐），加上 --apcu-autoloader 能把 classmap 缓存到共享内存，进一步减少文件读取。但它有前提：
- 必须所有 PHP worker 共享同一 APCu 实例（FPM 模式下默认满足，CLI 下不生效）
- APCu 的
apc.enabled=1且apc.shm_size足够（建议 ≥64M） - 不能和
--classmap-authoritative冲突——它俩可以共存，但 APCu 只缓存 classmap 结果，不改变权威性逻辑
上线前务必验证：var_dump(apcu_fetch('Composer\Autoload\ClassLoader::getClassMap')) 是否返回非空数组。
