classmap与psr-4本质区别在于加载机制：psr-4是按命名空间实时推导路径的规则式加载，classmap是预扫描生成类名到路径映射的查表式加载。
classmap 和 psr-4 的根本区别在哪？
本质不是“用哪个更好”，而是“解决什么问题”。psr-4 是按命名空间查路径的**规则式加载**，靠约定（类名 ⇄ 文件路径）实时推导；classmap 是提前扫描所有 PHP 文件、把每个类名硬编码映射到绝对路径的**查表式加载**。
这意味着：
-
psr-4不需要每次加新类就重生成映射 —— 只要文件放在对的目录、类名和命名空间匹配，自动生效 -
classmap必须执行composer dump-autoload（或install/update）才能感知新增类，否则直接报Class not found -
psr-4要求类必须有命名空间且文件名 = 类名（如HomeController→HomeController.php）；classmap对无命名空间、下划线风格（如Db_Connection）、甚至全局函数文件都兼容
什么时候必须用 classmap，而不是硬套 psr-4？
当你面对这些现实场景时，psr-4 会直接失效，classmap 是唯一靠谱选择：
- 老项目遗留的无命名空间类（比如
class Utils { ... }放在lib/Utils.php） - 第三方 SDK（尤其是非 Composer 包）使用 PEAR 风格命名（
Mail_Queue→Mail/Queue.php），且你无法改源码 - 想把某个独立工具文件（如
helpers/functions.php）里的全局函数也纳入自动加载范围（注意：这要用files，但常被误塞进classmap） - 某些 CLI 工具类或测试桩类，故意不声明命名空间，只为快速原型验证
{
"autoload": {
"psr-4": {
"App\": "src/"
},
"classmap": [
"lib/",
"legacy/BaseModel.php",
"vendor/some-old-sdk/"
]
}
}
性能差异真有那么大？别被“psr-4 更快”带偏了
开发期几乎没差别；但生产环境开启优化后，差距才显现：
- 未优化（
composer install默认）：psr-4每次 new 都要拼路径 +file_exists()判断，有 IO 开销；classmap直接查数组，更快 - 启用优化（
composer install -o或composer dump-autoload -o）：psr-4映射会被预编译进vendor/composer/autoload_psr4.php，和classmap查表速度基本持平 - 真正拖慢的是混用：比如在
psr-4下放了一个没命名空间的类，Composer 会默默跳过它，运行时报错，你还得回头排查为什么“明明文件在却找不到”
常见踩坑：classmap 配置写错，比 psr-4 更难 debug
psr-4 错了通常立刻报错（路径不存在 / 类名不匹配）；classmap 错了更隐蔽——它可能“成功扫描”，但扫不到你要的类，因为：
- 指定目录下没有
.php后缀文件（比如你写了"classmap": ["src"]，但里面全是.inc或.php5） - 类定义在条件语句里（
if (DEBUG) { class A {} }），扫描器直接忽略 - 路径是相对路径但拼错了，比如
"lib/utils"实际应为"lib/utils/"（少斜杠可能导致只扫文件不递归） - 执行了
dump-autoload却忘了加-a（--append）参数，导致旧映射被清空，而新目录又没扫全
最稳妥的做法：加完 classmap 后，手动打开 vendor/composer/autoload_classmap.php，搜你的类名，确认是否出现在那个大数组里。
