Class not found是自动加载失败，非文件缺失；根本原因是命名空间、目录结构、composer autoload配置或runtime/classmap缓存不匹配导致框架无法定位类。
Class not found 不是文件丢了，是自动加载机制压根没“看见”它。90% 的情况，类文件真实存在，但命名空间、路径、composer 配置或缓存之间有至少一处对不上。
确认命名空间与物理路径是否严格一致
ThinkPHP 依赖 PSR-4 规则做自动加载，它把 namespace 当作路径来拼——差一个字母、多一层目录、少一个反斜杠，都会失败。
-
appcontrollerIndexController必须对应app/controller/IndexController.php，不能是app/controller/indexcontroller.php（Linux 下完全不识别） - 命名空间末尾必须带反斜杠：
namespace appcontroller;，不是namespace appcontroller或namespace app/controller; - 类名必须与文件名完全一致：
class IndexController→ 文件名必须是IndexController.php，不能是indexcontroller.php或Indexcontroller.php - 如果类在
extend/目录下（比如插件），它的命名空间不能硬套app，得按实际目录结构写，例如extendpayAlipay对应extend/pay/Alipay.php，且需额外配置 autoload
检查 composer.json 的 autoload 配置是否生效
框架不会扫描整个项目找类，它只信 composer.json 里写的映射。改了目录、加了新模块、迁移了旧代码，这步最容易漏。
- 打开
composer.json，确认"autoload": {"psr-4": {}}里包含类似"app\": "app/"的映射（注意双反斜杠和结尾斜杠） - 如果类在
extend/或common/这类自定义目录下，必须显式加进去："extend\": "extend/" - 改完配置后，必须运行
composer dump-autoload -o；只跑composer install或composer update不会重建 autoload 映射 - 线上部署时若用了
--optimize-autoloader，本地改完composer.json后，务必同步执行该命令，否则服务器读的还是旧映射
排查 ThinkPHP 自己的运行时命名空间注册
除了 Composer，ThinkPHP 还支持用 Loader::addNamespace() 动态注册命名空间——这个机制绕过 Composer，也不会被 composer dump-autoload 捕获，常被忽略。
立即学习“PHP免费学习笔记（深入）”；
- 检查项目中是否有类似
Loader::addNamespace('plugin', './extend/plugin');的调用，通常出现在common.php、provider.php或插件初始化逻辑里 - 这类注册只在运行时生效，不写入任何文件，所以 IDE 不提示、
composer show看不到，但一旦路径写错（比如少个./或拼错目录名），就直接Class not found - 如果用了多应用模式，每个应用可能有自己的
app_namespace配置，要核对config/app.php里的'app_namespace' => 'app'是否匹配当前入口和控制器路径
别被“清缓存”误导：哪些操作根本没用
很多人一报错就狂清缓存、重启 PHP-FPM、删 runtime/，但这些对 autoload 问题基本无效——因为类路径索引不在那里存着。
-
php think clear清的是模板、日志、路由缓存等，不影响类加载路径 - 删
runtime/cache/或runtime/container/不重建vendor/composer/autoload_psr4.php - 重启 PHP-FPM 只重载进程，不刷新 Composer 的静态映射表
- 真正起作用的只有三件事：
composer dump-autoload -o、确认命名空间与路径、检查Loader::addNamespace()调用是否准确
最麻烦的是混合场景：Composer 映射写对了，Loader::addNamespace() 也注册了，但两者指向同一命名空间的不同路径——这时候框架会按优先级选一个，另一个直接失效，而错误堆栈往往不提示冲突来源。
