classmap 配置必须写在 composer.json 的 autoload 或 autoload-dev 中，值为路径数组，末尾带/递归扫描，不带则视为文件，支持*通配符；不执行 composer dump-autoload 则无效。
classmap 怎么配才生效
不运行 composer dump-autoload，配置就是废纸。Composer 不会监听文件变化，也不会在 require 或 new 时动态扫描——它只在你手动执行这条命令时，一次性把指定路径下的所有 .php、.inc、.hh 文件过一遍，提取里面的 class、interface、trait 声明，硬编码进 vendor/composer/autoload_classmap.php。
-
"classmap"必须写在composer.json的"autoload"（或"autoload-dev"）对象里，值是字符串数组 - 路径末尾带
/表示递归扫描目录；不带则当作具体文件处理（比如"lib/helpers.php"） - 支持
*通配符（如"legacy/DB_*.php"），但不支持**；旧版 Composer（* 都不认，只接受目录或完整文件名 - 路径必须真实存在，否则
dump-autoload会报 warning，但继续执行——容易误以为“配对了”，其实什么都没扫到
classmap 扫不到类的常见原因
不是代码写错了，而是扫描机制本身有盲区。classmap 不执行 PHP 代码，只做词法解析，所以它看不见条件分支里的类、动态定义、别名或语法错误。
- 文件里写了
if (false) { class A {} }？照样被扫进去——它不关心逻辑，只找class关键字 - 用了
class_alias('OldClass', 'NewClass')？没用，classmap 不解析这个 - 类是
eval("class X {}")动态生成的？完全不可见 - PHP 语法错误（比如少个
;或括号不匹配）？该文件直接跳过，不报错也不提示，默默忽略 - 两个不同文件都定义了
class User？后扫描到的会覆盖前一个，不警告，但运行时行为不可控
和 PSR-4 混用时谁先加载
PSR-4 永远优先。Composer 加载顺序是：先查 PSR-4 → 再 PSR-0 → 最后才是 classmap。这意味着，哪怕你在 classmap 里扫了整个 src/ 目录，只要一个类符合 PSR-4 规则（比如 AppControllerUserController 对应 src/Controller/UserController.php），classmap 里的同名映射就永远不会触发。
- 想让老代码走 classmap，就得确保它们不在任何 PSR-4 映射路径内——比如统一挪到
legacy/或lib/，且 PSR-4 规则不覆盖这些目录 - 重复扫描同一目录（比如 PSR-4 已映射
"App\" → "src/"，又在 classmap 加了"src/"）只会拖慢dump-autoload速度、增大autoload_classmap.php，毫无收益 - 非命名空间类（比如裸
class Database）是 classmap 的典型场景，PSR-4 根本不处理这类类，所以放心扫
生成的 classmap 文件在哪、怎么验证
结果全在 vendor/composer/autoload_classmap.php，它就是一个返回大数组的 PHP 文件，键是类名（标准化为全大写），值是绝对路径，里面还用了 $vendorDir 这个 Composer 自动替换的常量。
- 想确认某个类是否被扫进去了，直接打开这个文件搜类名就行，比猜配置靠谱得多
- Linux 上大小写敏感，Windows/macOS 可能不报错，但部署后
new Database()找不到类——务必保证文件名与类名大小写完全一致 - 修改了
classmap配置或新增了类文件，必须重跑composer dump-autoload，否则 autoload_classmap.php 不更新 - 性能上，classmap 查表是 O(1)，比 PSR-4 的多层
file_exists()快；但代价是灵活性归零——改了类就得再 dump 一次
classmap 的本质是“静态快照”，不是智能代理。它省掉的是运行时路径推导，换来的是一次性生成、不可热更、必须人工维护的映射表。用它，就得接受这种契约。
