composer dump-autoload 默认不生成 optimized autoloader，因仅重建 autoload_static.php 和 autoload_files.php；需显式加 --optimize 或 -o 才扫描类并生成 autoload_classmap.php。
composer dump-autoload 为什么没生成 optimized autoloader
默认 composer dump-autoload 只重建 autoload_static.php 和 autoload_files.php，不触发类映射优化。真正生成 vendor/composer/autoload_classmap.php（即“optimized autoloader”）必须显式加 --optimize 或 -o 参数。
- 没加
--optimize：只做 PSR-4/PSR-0 映射注册，类加载仍靠实时文件扫描 - 加了
--optimize：Composer 扫描所有src和lib下的 PHP 文件，把每个类名到文件路径的映射提前写死进autoload_classmap.php，跳过命名空间推导和目录遍历 - 如果项目用了大量
classmap配置（比如 legacy 目录），--optimize会一并纳入，但要注意路径是否仍有效
composer install --optimize-autoloader vs composer dump-autoload --optimize
两者最终效果一致：都生成 autoload_classmap.php 并启用 classmap 加载模式。区别在于触发时机和上下文：
-
composer install --optimize-autoloader：只在首次安装或锁文件变更时生效；适合 CI/CD 构建阶段，且隐含--no-dev（除非你加了--dev） -
composer dump-autoload --optimize：可随时执行，不影响依赖版本；适合本地开发调试后手动优化，也支持单独加--classmap-authoritative - 若同时用
--classmap-authoritative，Autoloader 会完全忽略 PSR-4 查找逻辑，只查 classmap —— 这能提速，但要求所有类必须被扫描到，漏掉就Class not found
autoload_classmap.php 生成失败或不完整怎么办
常见现象是运行 composer dump-autoload --optimize 后，autoload_classmap.php 文件为空或条目极少。根本原因通常是 Composer 没找到可扫描的 PHP 类文件：
- 检查
composer.json的"autoload"段是否配置了"classmap"路径，且路径存在、非空、有 .php 文件 - 确认 PSR-4 声明的
"psr-4"命名空间路径（如"App\": "src/"）下确实有 PHP 文件，且文件里有class声明（不含declare(strict_types=1)等前置语句干扰解析） - Windows 下注意路径分隔符：Composer 内部用
/，但你的composer.json里写\或/都行，只要实际目录可访问 - 某些 IDE 自动生成的 stub 文件（如
src/Stub/Example.php）若没真实类定义，也会被跳过
classmap 加载对性能的真实影响有多大
在 CLI 环境或高并发 Web 场景下，启用 classmap 可减少每次请求中约 5–20ms 的文件系统查找开销（取决于 PSR-4 层级深度和 vendor 包数量）。但收益有边界：
- PHP 7.4+ 开启
opcache.enable_cli=1后，未优化的 autoloader 性能差距明显缩小 - 若项目本身类数少于 200 个，差异几乎不可测；超过 2000 个类时，
--classmap-authoritative才值得考虑 - 副作用：每次新增类都要重新运行
composer dump-autoload --optimize，否则新类无法加载 —— 这点常被忽略，尤其在热更新或插件机制里
--classmap-authoritative，就必须确保每次部署前都重跑命令，且不能依赖动态类注册。 
