composer dump-autoload --optimize 已被弃用，因 Composer 2.0+ 默认启用 classmap 自动发现与 JIT 优化，且现代 PHP+Opcache 下其性能收益极小，反致开发不便与类加载风险。
为什么 composer dump-autoload --optimize 不再推荐
Composer 2.0+ 默认启用 classmap 自动发现和 JIT 优化，--optimize（即 --classmap-authoritative 的旧别名）已被弃用，强行使用会触发警告。它曾强制跳过 PSR-4/PSR-0 动态查找，但代价是：新增类不自动生效、开发期频繁重生成、且对现代 PHP（8.0+）+ Opcache 实际收益极小。
真正有效的优化路径是让 autoloader 更“确定”、更“精简”：
- 确保
"autoload": {"classmap": [...]}只包含真正需要扫描的目录（如src/），避免把tests/或vendor/误加进去 - 移除未使用的 autoload 规则（比如残留的
psr-0配置） - 若项目含大量小工具类（如 Laravel 的
helpers.php），改用"autoload": {"files": ["src/helpers.php"]}显式加载，比动态匹配快一个数量级
如何启用权威模式（--classmap-authoritative）并安全使用
该模式告诉 Composer：“所有类都必须在 classmap 中，找不到就直接报错，别 fallback 到 PSR-4 查找”。它能显著减少文件系统 stat 调用，但前提是 classmap 必须完整覆盖运行时所有类。
实操建议：
- 仅在生产环境启用：
composer install --no-dev --classmap-authoritative - CI/CD 构建阶段务必运行
composer dump-autoload --classmap-authoritative --no-dev并验证是否漏类（可配合php -l扫描或启动时观察Class not found错误） - 禁用
apcu或opcache.enable_cli=1下的 CLI 环境测试，避免缓存掩盖问题 - 注意：Laravel 的
Route::get()动态闭包、Symfony 的config/services.php中匿名类等，可能因 classmap 未收录而失败
composer install vs composer update 对 autoloader 的影响
二者生成的 autoloader 结构一致，但触发时机和风险不同：
-
composer install读取composer.lock，复用已验证的 classmap，速度快、结果稳定；适合部署 -
composer update重新解析依赖树、重新扫描所有 autoload 目录，耗时长，且可能因新版本包引入未声明的 autoload 规则（如某包突然加了files加载）导致 classmap 冗余或冲突 - 若发现 autoloader 变慢，先检查
vendor/composer/autoload_classmap.php是否膨胀（比如含数百个测试类路径），再反查是哪个包的autoload配置不合理
PHP Opcache + Composer autoloader 的协同要点
Opcache 缓存的是编译后的 opcode，不是 classmap 本身，但它会缓存 include/require 的文件路径映射。若 autoloader 过于动态（如大量 file_exists() 判断），Opcache 效果会被削弱。
关键动作：
- 确保
opcache.revalidate_freq=0（生产环境），避免每次请求都 stat autoload 文件 - 启用
opcache.validate_timestamps=0后，必须手动opcache_reset()或重启 Web 服务才能更新 autoloader —— 这意味着composer dump-autoload后不能只刷新页面 - 用
opcache_get_status()['scripts']检查vendor/composer/ClassLoader.php和autoload_classmap.php是否被缓存；若没出现，说明路径不在opcache.file_cache范围内或被排除
最易被忽略的一点：Composer 的 classmap 是纯 PHP 数组，没有函数调用开销，但如果你在 autoload_files.php 里写了带 I/O 或 DB 查询的代码，Opcache 也救不了它。
