dump-autoload --classmap 有时反而变慢，因它强制扫描所有PHP文件生成庞大类映射数组，对标准PSR-4项目，查大数组比直接拼路径更耗时；且若误扫测试/冗余目录或含动态类（如Facade），还会引发fallback或错误。
为什么 dump-autoload --classmap 有时反而让自动加载变慢
它强制扫描所有 PHP 文件、提取类名并写入 vendor/composer/autoload_classmap.php，适合无命名空间或 psr-0 的老旧项目；但对标准 PSR-4 项目，类映射会膨胀（尤其含测试文件、stubs、第三方冗余目录时），导致每次加载都查一张巨大数组，比直接按 PSR-4 规则拼路径还慢。
- 默认不扫描
tests/、Examples/等目录，但如果你在composer.json的"autoload"或"autoload-dev"里显式加了这些路径，它们就会被塞进类映射 -
--classmap-authoritative会让 Composer 完全跳过文件系统检查——一旦类不在映射里就直接报错，适合部署环境，但开发中改了类名却忘了重跑 dump-autoload，就会卡住 - 若项目用了
class_alias()或动态注册的类（如 Laravel 的 Facade），类映射无法识别，运行时仍要 fallback 到常规查找
怎么安全地用 dump-autoload --classmap 加速生产环境
只对明确知道“不会动态生成类”且“目录结构稳定”的子集启用类映射，而不是全量扫描。
- 在
composer.json中用"classmap"字段精确指定要扫描的目录："autoload": { "psr-4": { "App\\": "app/" }, "classmap": ["src/Legacy/", "lib/Helpers.php"] } - 执行时加
--no-dev，避免把tests/或vendor/bin下的工具脚本也扫进去 - CI/CD 部署后立刻运行：
composer dump-autoload --classmap-authoritative --no-dev，确保线上不走任何文件系统 stat 调用
vendor/composer/autoload_classmap.php 被意外修改怎么办
这个文件是自动生成的，不应手动编辑。但有些 IDE 或脚本会误触它，导致类找不到——因为 Composer 不校验该文件内容合法性，只原样载入。
- 检查是否在
composer.json中漏写了某个旧类所在的路径，导致 dump 后映射缺失（常见于迁移中未清理的autoload.files） - 运行
composer dump-autoload -v查看详细扫描日志，确认目标类文件是否真被读取 - 临时删掉
vendor/composer/autoload_classmap.php，再跑一次dump-autoload，排除文件损坏可能
