classmap 配置后类找不到的根源是未执行 composer dump-autoload，该命令才能生成 vendor/composer/autoload_classmap.php 映射表；跳过则新增类永不生效。
classmap 不是“写完就自动生效”的加载方式，它必须显式执行 composer dump-autoload 才会扫描目录、生成映射表并写入 vendor/composer/autoload_classmap.php。跳过这步，新增类文件永远无法被加载。
classmap 配置后为什么类还是找不到？
常见错误是只改了 composer.json 却没运行生成命令。即使目录结构完全正确，autoload_classmap.php 文件里没有对应条目，PHP 就根本不会知道这个类存在。
- 确认
composer.json中的classmap值是相对项目根目录的路径，比如"src/"或"libs/"，不能写成./src/或绝对路径 - 路径末尾不加斜杠也可以，但建议统一用
"src/"形式，避免某些旧版 Composer 解析异常 - 如果类文件在子目录中（如
src/Utils/Helper.php），且没声明命名空间，classmap仍能加载；但若声明了namespace App\Utils;，则需确保类名与文件路径逻辑一致（否则 PSR-4 更合适） - 执行
composer dump-autoload后，打开vendor/composer/autoload_classmap.php，搜索你的类名，确认键值对已写入
什么时候该用 classmap 而不是 psr-4？
核心判断依据是：类有没有规范命名空间，以及你是否需要“全量预加载”。
- 第三方 SDK、遗留代码、无命名空间的工具类（如
functions.php里一堆function foo()）——用classmap最省事 - 项目里混用多种命名风格、或存在同名类在不同目录（如多个
Config.php）——classmap可靠，PSR-4 会冲突 - 生产环境追求启动速度，且类数量稳定 —— 开启
--optimize-autoloader后，classmap比 PSR-4 查找快，因为它是纯数组isset($map[$class])判断，无路径拼接和file_exists()开销 - 开发阶段频繁增删类文件？别依赖
classmap，它每次都要dump-autoload，不如 PSR-4 按需解析来得轻量
classmap + --classmap-authoritative 是什么效果？
加上 --classmap-authoritative 参数后，Composer 加载器会彻底忽略 PSR-4/PSR-0 规则，只信任 autoload_classmap.php 里的映射。这意味着：
- 任何未出现在
autoload_classmap.php中的类，哪怕它符合 PSR-4 路径规则，也会直接报Class not found - 适合部署后类结构冻结的场景（如 SaaS 多租户系统打固定包），能杜绝意外加载非预期文件
- 必须配合
--optimize-autoloader使用，否则权威模式下缺失映射等于功能不可用 - 命令示例：
composer install --no-dev --optimize-autoloader --classmap-authoritative
真正容易被忽略的是：classmap 的“静态性”——它不感知文件变更，也不做运行时校验。上线前漏跑一次 dump-autoload，或者 CI/CD 流水线里没固化这步，就会导致新类静默失效。别指望它像 PSR-4 那样“猜路径”，它只认自己记下来的那一张表。
