composer dump-autoload 默认不生成 classmap，仅更新 PSR-4/PSR-0 规则；需显式添加 --classmap-authoritative 才构建并启用权威 classmap。
composer dump-autoload 为什么没生成 classmap
默认情况下 composer dump-autoload 只更新自动加载规则（PSR-4/PSR-0），不生成 classmap。这是最常被误以为“失效”的原因。
- 必须显式加
--classmap-authoritative或--optimize（旧版）才触发 classmap 构建 -
--classmap-authoritative是当前推荐方式，它让 autoloader 完全依赖 classmap，跳过文件系统扫描 - 如果项目里有
classmap配置（如"classmap": ["src/legacy/"]），它只对这些路径生效，不是全局扫描 - 注意：classmap 不会包含 PSR-4 映射的类，除非你强制把整个目录加进
classmap数组
什么时候该用 classmap？哪些场景真能提效
classmap 的加速效果只在特定条件下明显：大量小文件、无命名空间的传统 PHP 类、或部署后禁止文件系统遍历的环境（如某些容器或函数计算）。
- 典型适用：老项目遗留的
include_once('Utils.php')风格代码，且无法重构为 PSR-4 - 不适用：纯 PSR-4 项目 + 开发阶段 —— classmap 不会比 PSR-4 快，反而因失去动态发现能力更难调试
- 生产部署时配合
--classmap-authoritative可减少file_exists()调用，对 I/O 敏感环境有意义 - CI/CD 中生成 classmap 后再打包，能避免运行时扫描 vendor 目录（尤其当 vendor 被挂载为只读）
classmap 生成后为什么类还是找不到
常见不是命令没跑，而是 classmap 的覆盖逻辑和路径解析容易出错。
- classmap 只记录
.php文件中定义的类/接口/trait，不处理require或eval动态加载的类 - 路径是相对于
composer.json所在目录的，比如配置"classmap": ["lib/"]，但实际文件在src/lib/，就不会被收录 - 如果类文件里用了
namespace但没按 PSR-4 规则命名，classmap 虽然存了路径，但ClassLoader::findFile()可能因命名冲突跳过它 - 运行
composer dump-autoload -v查看详细输出，确认目标文件是否出现在 “Generating autoload files” 日志里
classmap 和 optimize-autoloader 的关系
"optimize-autoloader": true 在 composer install 时等价于加 --optimize-autoloader，但这个 flag 已被弃用；现在应统一用 --classmap-authoritative。
- 旧版
--optimize会生成 classmap 并启用“优化模式”，但不强制跳过文件检查；新版--classmap-authoritative更严格，autoloader 直接查表，查不到就抛错 -
"classmap-authoritative": true写进composer.json的config段，可确保所有环境行为一致 - 二者都要求所有类必须能被静态分析到，所以动态注册的类（如通过
spl_autoload_register手动追加）会失效 - PHP 8.1+ 下若开启 opcache，classmap 对性能提升边际递减，重点应放在 opcache 配置而非 classmap
--classmap-authoritative，新增一个没被扫描到的类文件，就会直接 Class not found，连提示你少 run 一次 dump 的机会都没有。 
