不会，composer dump-autoload 默认不生成 autoload_classmap.php；仅当加 --optimize-autoloader（-o）或 --classmap-authoritative（-a）参数，或项目配置了 "classmap" 字段时，才会重建该文件。
composer dump-autoload 会重新生成 autoload_classmap.php 吗
不会。默认情况下 composer dump-autoload 只生成或更新 autoload_files.php、autoload_namespaces.php、autoload_psr4.php 等，但**不生成类映射（classmap）文件**，除非你显式启用 classmap 生成。
类映射文件（如 vendor/composer/autoload_classmap.php）只在以下情况被写入：
- 执行
composer dump-autoload --classmap-authoritative或--optimize-autoloader（后者是前者的别名） - 项目中配置了
"classmap": ["src/", "lib/"]且启用了优化选项 -
composer install或composer update时加了-o或--optimize-autoloader
如何让 Composer 脚本自动触发 classmap 更新
Composer 的 scripts 支持在生命周期事件（如 post-autoload-dump）中运行命令，但注意：post-autoload-dump 默认不触发 classmap 生成——它只在真正执行了 autoloader 重建后才运行，而是否包含 classmap 取决于是否加了优化标志。
正确做法是在脚本中**显式调用带优化参数的命令**：
{
"scripts": {
"post-update-cmd": [
"composer dump-autoload -o"
],
"post-install-cmd": [
"composer dump-autoload -o"
]
}
}
这样每次 composer install 或 composer update 完成后，都会强制重新生成权威类映射文件。
如果你只想在开发环境跳过 classmap（比如为了加快本地迭代），可配合环境变量控制：
"post-update-cmd": [
"@php -r \"if (getenv('COMPOSER_DEV_MODE') !== '1') { system('composer dump-autoload -o'); }\""
]
classmap 模式下新增类为什么没被识别
常见原因不是脚本没跑，而是 classmap 扫描路径没覆盖到新类所在目录。
检查以下三点：
-
composer.json中"autoload": {"classmap": [...]}是否包含新类所在的路径（支持相对路径，如"app/Models"） - 路径是否拼写错误，或遗漏了尾部斜杠（
"app/Models"✅，"app/Models/"✅，但"app/Models/*"❌ —— classmap 不支持 glob） - 执行
composer dump-autoload -o后，打开vendor/composer/autoload_classmap.php，搜索你的类名，确认是否已写入数组
如果类在 vendor/ 外但不在 classmap 列表里，即使加了 -o 也不会被收录——classmap 不是“全盘扫描”，它只扫你声明的路径。
生产环境部署时 classmap 更新失败的典型表现
最常遇到的是：CI/CD 流水线里跑了 composer install --no-dev -o，但上线后报 Class not found。
根本原因往往是：
- 代码变更后未提交
composer.lock，导致install拉取的依赖版本与本地不一致，classmap 引用路径错乱 -
autoload_classmap.php被 Git 忽略（.gitignore 里写了/vendor），但 CI 构建机上又没 clean 掉旧的vendor/，残留旧 classmap - 使用了 symlink 部署，但
vendor/composer/autoload_classmap.php是硬编码绝对路径（其实不是，它是纯数组，无路径依赖；但若 classmap 扫描了../shared/src这类跨目录路径，symlink 下实际路径可能失效）
稳妥做法：部署脚本中始终执行 rm -rf vendor && composer install --no-dev -o，不复用旧 vendor。
classmap 的本质是一次性静态映射，一旦生成就和源码结构强绑定——这点比 PSR-4 更脆弱，也更需要你盯住扫描路径和构建一致性。
