classmap配置需手动执行composer dump-autoload才生效，且必须置于composer.json的autoload或autoload-dev的classmap数组中；路径带/递归扫描、不带为文件、支持*通配符；失效主因是PSR-4优先覆盖或未被扫描到。
classmap 不是“配完就生效”的自动机制，它必须手动执行 composer dump-autoload 才会写入 vendor/composer/autoload_classmap.php；不运行这条命令，配置等于没写。
classmap 配置写在哪、怎么写才有效
必须放在 composer.json 的 autoload（或 autoload-dev）对象里，作为 classmap 字段的字符串数组：
- 路径末尾带
/表示递归扫描整个目录（如"lib/"） - 不带斜杠视为具体文件（如
"includes/functions.php"） - 支持
*通配符（如"legacy/DB_*.php"），但不支持**或更复杂的 glob - 路径必须真实存在，否则
dump-autoload仅报 warning 并继续执行——你可能以为扫到了，其实什么都没进映射表
为什么 new Database() 没加载？常见失效原因
classmap 失效往往不是配置错，而是加载顺序或扫描盲区导致：
- PSR-4 规则优先级永远高于 classmap：如果
"App\" → "src/"已配置，而Database类恰好在src/Database.php里，哪怕它没命名空间，也会被 PSR-4 “误匹配”并跳过 classmap - 类名大小写不一致：Windows/macOS 可能不报错，但部署到 Linux 就
Class 'database' not found - 文件里有语法错误（比如漏了
;或括号不匹配），classmap 扫描时直接跳过该文件，且不提示 - 两个不同文件都定义了
class User，后扫描到的会覆盖前一个，new User()加载的是哪个，取决于文件遍历顺序，不可控
怎么验证 classmap 是否真生效了
别只看命令有没有报错，要查生成结果：
- 运行
composer dump-autoload后，打开vendor/composer/autoload_classmap.php - 搜索你期望的类名（如
Database），确认键值对存在且路径正确 - 路径中含
$vendorDir是正常的，Composer 运行时会自动替换为真实路径 - 如果没找到，回退检查：路径拼写、是否存在、是否被 PSR-4 覆盖、文件是否有语法错误
classmap 的核心约束很硬：它不解析命名空间、不执行代码、不监听变化、不处理动态定义。所有“为什么没加载”的问题，基本都落在“没扫到”或“被 PSR-4 截胡”这两条线上。最稳妥的做法是——把老代码统一挪到 legacy/ 或 lib/ 这类明确不被 PSR-4 映射的目录，并确保 dump-autoload 真的跑过了。
