ClassMap 需显式启用（如 –classmap-authoritative），生成静态类名→路径映射表，启用后完全跳过 PSR-4/PSR-0 查找；适合 CLI 工具或 Serverless 环境，Web 应用中反而因体积大、warmup 慢而降低性能。
ClassMap 生成原理与触发时机
Composer 的 classmap 不是默认启用的自动加载机制，它只在你显式执行 composer dump-autoload --classmap-authoritative 或 composer install --optimize-autoloader 时才生成。它的本质是把所有符合扫描规则的 PHP 文件中定义的类、接口、trait 全部提前解析出来，写进 vendor/composer/autoload_classmap.php 里，形成一张“类名 → 文件路径”的静态映射表。
关键点在于：一旦启用 --classmap-authoritative，Composer 就完全跳过 PSR-4/PSR-0 的文件查找逻辑，只查这张表——查不到就直接抛 Class not found，不再 fallback。
什么时候该用 ClassMap？哪些场景反而会变慢
ClassMap 对「类数量多但实际运行时只用其中一小部分」的项目反而有害。比如 Laravel 的 vendor/ 下有上万类，但一次 HTTP 请求通常只加载几百个；此时 classmap 文件体积大（几 MB）、PHP 解析开销高，且无法利用 OPcache 的文件级缓存粒度优势。
更适合的场景是：
- 命令行工具类项目（如 PHPCS、PHPStan），每次运行几乎加载全部依赖
- 闭包打包部署（如 Serverless 函数），需消除动态文件查找、避免 runtime 扫描
- 明确禁用动态 autoload（
"classmap-authoritative": true在composer.json中）并接受“漏类即报错”的强约束环境
如何安全启用并验证 ClassMap 生效
不要直接改 composer.json 然后跑 install —— 这容易误伤开发体验。推荐分步操作：
