Composer 默认不生成 classmap 因其体积大、易过期且开发中类频繁增删；启用需加 -o 参数，生产环境务必配合 --no-dev；动态类名、OPcache 配置不当或 vendor 污染时 classmap 反降性能。
composer dump-autoload 为什么默认不生成 classmap？
因为 composer dump-autoload 默认使用 psr-4 自动加载策略，它依赖文件系统实时查找类文件，启动快但运行时有 I/O 开销；而 classmap 是一次性扫描全部 PHP 文件、生成静态映射表，后续加载完全跳过文件查找，适合部署后稳定环境。
但 classmap 会显著增加 autoloader 文件体积，且开发中类增删频繁时容易过期——所以 Composer 默认不启用它。
如何用 dump-autoload 启用高效 classmap 映射？
执行以下命令即可生成完整 classmap：
composer dump-autoload -o
-o（optimize）参数等价于 --optimize-autoloader，它会：
- 扫描
vendor/和项目中所有autoload配置的目录（含psr-4、psr-0、classmap和files） - 将所有可发现的类名→文件路径写入
vendor/composer/autoload_classmap.php - 禁用动态文件查找逻辑，直接查表返回路径
注意：-o 在含大量小包（如 Laravel 的 helper 函数包）的项目中可能让 classmap 文件达数 MB，但加载速度提升通常在 15%–40%，尤其对 CLI 命令或高并发 Web 请求明显。
生产环境必须加 --no-dev 吗？
是的，否则 classmap 会包含 require-dev 中的包（如 PHPUnit、phpstan），这些类在运行时根本不会被加载，纯属浪费内存和磁盘空间。
推荐生产部署命令：
composer install --no-dev --optimize-autoloader
或已有依赖时：
composer dump-autoload --optimize-autoloader --no-dev
两者效果一致：跳过 dev 包扫描，classmap 更精简，autoload_files.php 和 autoload_static.php 也只保留运行时必需项。
什么时候 classmap 反而拖慢性能？
不是所有场景都适合 classmap。以下情况要谨慎：
- 项目使用了大量“运行时动态类名”（如
class_exists($name, false)+ 手动 require），classmap 无法覆盖这类逻辑 - 启用了 OPcache 但未配置
opcache.enable_file_override=1，classmap 生成的长路径字符串可能触发 OPcache 内存碎片 - 容器化部署中反复
composer install却没清理旧 vendor，多个版本的autoload_classmap.php被重复加载（常见于 CI 构建缓存污染） - PHP 版本
classmap 的优势只在“确定类存在且加载路径固定”的场景下成立；一旦涉及反射、插件机制或热重载，就得退回到标准 autoload 策略。
