composer dump-autoload 不会自动清理 classmap 是因为它仅按 composer.json 中配置的路径重新扫描并生成映射，不校验文件是否存在或类是否有效；残留条目会导致 class not found 消失但实际类已删、autoload_classmap.php 膨胀、ci 静态分析失败等问题。
composer dump-autoload 为什么不会自动清理 classmap？
因为 composer dump-autoload 默认只重新扫描 classmap 配置里指定的路径，不管里面实际有没有类文件。它不校验文件是否存在、类是否被声明、命名空间是否匹配——只要路径下有 PHP 文件（哪怕只是空文件或注释文件），就可能被写进 vendor/composer/autoload_classmap.php。
常见错误现象：Class Not Found 报错消失但实际类已删除；vendor/composer/autoload_classmap.php 越来越大；CI 构建时因残留条目导致静态分析失败。
使用场景：重构后删了大量旧类、迁移 legacy 目录、清理历史遗留的 classmap 配置项。
- 手动删
vendor/composer/autoload_classmap.php没用——下次dump-autoload又生成 -
composer install或update会强制重生成 classmap，不跳过缺失文件 - 真正要清理，得让 Composer “扫描时跳过不存在的路径”，而不是“生成后再删”
如何安全移除已不存在的 classmap 路径？
Composer 本身不提供“dry-run 清理 classmap”命令，但可以通过修改 composer.json + 强制重生成来达成效果。关键不是删条目，而是删掉那些指向已不存在目录/文件的 classmap 配置项。
操作前先确认哪些路径已失效：
- 运行
ls -la对照composer.json中"autoload": {"classmap": [...]}的每个路径 - 对每个路径执行
find path/to/dir -name "*.php" | head -n1，看是否真有可解析的类文件 - 特别注意通配符路径（如
"legacy/*"）——如果legacy/目录已删，整条必须移除
改完立刻执行：
composer dump-autoload --optimize --classmap-authoritative
这会跳过未配置的路径，且不尝试 fallback 到 PSR-4，从而暴露遗漏问题——如果你删错了路径，这里就会报 Class XXX not found，正好反向验证。
classmap 条目残留会导致什么实际问题？
不是所有残留都立即报错，但会在特定条件下触发异常行为：
- PHP 8.2+ 的
Deprecated: Creation of dynamic property可能来自 classmap 加载了一个只有__set但无类定义的空文件 - 静态分析工具（如 PHPStan、Psalm）扫描
vendor/composer/autoload_classmap.php时，会把无效条目当真实类处理，导致误报“未使用类”或“继承链断裂” - 部署到只读文件系统（如某些容器环境）时，
dump-autoload失败，因为试图往已删路径里写缓存 - 某些 IDE（如 PhpStorm）基于 classmap 做索引，残留条目会让“Go to Class”跳转到 404 文件
性能影响有限，但兼容性风险集中在工具链和协作环节——你本地没问题，队友的 PHPStan 就过不了。
有没有脚本化检测方式？
没有官方命令，但可以用一行 shell 快速筛出“配置存在但路径不存在”的条目：
jq -r '.autoload.classmap[]' composer.json 2>/dev/null | while read p; do [[ ! -e "$p" ]] && echo "MISSING: $p"; done
注意：jq 需要安装；路径是相对于 composer.json 所在目录的；Windows 用户请改用 PowerShell 或 Git Bash。
更稳妥的做法是加个 CI 检查步骤：
- 在
.github/workflows/ci.yml里加run: bash -c 'jq ...' - 或者用
composer validate --strict，它虽不检查 classmap 路径有效性，但能发现语法错误和明显结构问题
真正麻烦的不是“怎么删”，而是“删完谁来保证不再加回来”——团队里有人顺手加 "classmap": ["src/old"] 却忘了删目录，这种事每天都在发生。
