class 'xxx' not found 错误多因命名空间与psr-4路径不匹配、use语句误用、autoload未注册或配置错误、opcache缓存未清理等导致，需逐层验证。
Class 'XXX' not found 错误到底缺了哪一环
这个错误八成不是类不存在，而是命名空间没对上。PHP 加载类时会把 namespace 和 use 语句拼成完整类名，再按 PSR-4 规则去文件系统里找——中间任一环节断掉都会报这错。
常见踩坑点：
-
namespace声明写在了declare或if语句块里（必须是文件最顶部，前面只能有declare和注释） -
use语句写错了别名，比如use AppModelsUser as UserModel;，但后面写了new User() - 文件路径和命名空间不匹配：类
AppServicesLogger必须放在src/Services/Logger.php（假设 PSR-4 root 是src/） - 自动加载器没注册，比如用原生 PHP 没调
spl_autoload_register()，或 Composer 的vendor/autoload.php没引入
use 语句失效的几种典型场景
use 只影响当前文件内对类名的解析，它不“导入代码”，也不改变作用域规则。很多问题出在误解它的行为。
容易出错的情况：
立即学习“PHP免费学习笔记（深入）”；
- 在函数内部写
use（语法直接报错，use必须在文件作用域） - 用了全限定名却忘了开头的反斜杠：
DateTime正确，DateTime会被当成当前命名空间下的CurrentNamespaceDateTime - 同名类冲突时没处理：比如同时
use DateTime;和use AppUtilsDateTime;，必须用as显式重命名其中一个 - trait 或 interface 也得
use，但不能和 class 混用同一行（use A, B;只适用于 trait）
composer dump-autoload 后还是找不到类
执行 composer dump-autoload 并不会帮你修路径或命名空间，它只是根据 composer.json 里的 autoload 配置重新生成映射表。如果配置本身有问题，重生成也没用。
检查重点：
-
composer.json中autoload的psr-4键值对是否漏了结尾的\（如"App\": "src/"，少一个反斜杠就完全不匹配） - 类文件扩展名是不是
.php（Composer 默认只扫描.php，写成.inc或没后缀不会被收录） - 运行命令的当前目录是否在项目根目录（否则
composer找不到composer.json） - 开发环境开了 OPCache 且没清理，旧的类映射还在缓存里，可临时加
opcache_reset();测试
测试命名空间时绕过自动加载直接 require
当不确定是命名空间问题还是自动加载问题时，最干净的验证方式是跳过 autoload，手动 require 文件并用全限定名实例化。
例如：
require 'src/Services/Cache.php'; $cache = new AppServicesCache();
这样能快速定位：如果成功，说明是 autoload 配置或 use 写法问题；如果仍报错，大概率是 namespace 声明位置不对、或者文件里根本没写 class Cache。
注意：require 的路径必须准确，且该文件里 namespace 必须和全限定名严格一致，包括大小写——Linux 下大小写敏感，AppServicescache 和 AppServicesCache 是两个东西。
命名空间错误真正难调试的地方，往往不是语法写错，而是多个上下文叠加：PSR-4 路径映射 + 文件系统大小写 + OPCache 缓存 + IDE 自动补全误导。每次只改一处，用 get_declared_classes() 或 class_exists('App\Xxx', false)（第二个参数设为 false 表示不触发 autoload）来逐层验证，比猜快得多。
