类找不到主因是自动加载失败而非文件丢失，需检查Composer配置、PSR-4路径映射、命名空间与目录结构一致性、大小写、OPcache缓存及框架启动时机。
类找不到，90% 是自动加载没走通，不是文件真丢了。
Composer autoloader 没生效或配置错
PHP 框架（Laravel、Symfony、ThinkPHP 等）依赖 Composer 的 autoload 机制找类。如果 composer.json 里 "autoload" 或 "autoload-dev" 配置路径不对、命名空间不匹配，或者没运行 composer dump-autoload，new SomeClass() 就会直接报 Class 'AppSomeClass' not found。
- 检查
composer.json中"psr-4"映射是否覆盖了你的类路径，比如"App\": "app/"要求类名AppHttpControllersIndexController对应app/Http/Controllers/IndexController.php - 新增类后必须执行
composer dump-autoload -o（加-o生成优化后的 classmap，尤其在生产环境） - 确认当前工作目录是项目根目录（即含
composer.json的目录），否则vendor/autoload.php可能没被正确引入
文件命名或命名空间与 PSR-4 不一致
PSR-4 要求严格对应：命名空间层级 = 目录结构，类名 = 文件名（含大小写）。哪怕只差一个字母大小写，Linux 下就加载失败。
-
namespace AppModels;的类，必须放在app/Models/下，且文件名必须是User.php（不能是user.php或UserModel.php） - 检查类定义开头是否有
namespace，有没有漏写分号、多写斜杠，比如namespace App\Models;（双反斜杠是转义，实际变成AppModels，但容易误写成namespace App\\Models;） - 用
php -l User.php先语法校验，排除因 parse error 导致类未被解析的情况
框架启动流程中提前使用了未加载的类
有些框架（如 Laravel）在服务提供者注册、中间件加载或配置解析阶段就可能触发类实例化。如果此时自动加载器还没完全初始化，或某处用了 class_exists('XXX', false) 并设为 false（不触发 autoload），就会静默失败。
立即学习“PHP免费学习笔记（深入）”；
- 搜索代码里是否在
config/或bootstrap/目录下有硬编码的new XXX或app(XXX::class)，这些地方往往早于 autoload 完全就绪 - 检查是否在
composer.json的"autoload"里漏掉了某个关键目录，例如只配了"App\"却忘了"Database\Factories\" - 临时在入口文件（如
public/index.php）顶部加var_dump(get_included_files());，确认vendor/autoload.php是否已被加载
OPcache 缓存了旧的 autoload 映射
启用 OPcache 后，composer dump-autoload 更新了 vendor/composer/autoload_classmap.php，但 OPcache 可能还缓存着旧的 classmap，导致新类“看不见”。
- 开发时可临时禁用 OPcache：
opcache.enable=0（php.ini）或通过opcache_reset()手动刷新 - 上线后若更新类后仍报错，优先执行
opcache_reset()，而不是反复重装 Composer - 注意 CLI 和 Web SAPI 的 OPcache 是分开的，
php -v看到的 OPcache 状态 ≠ Apache/Nginx 下的 OPcache 状态
真正卡住的时候，别急着重装框架——先 composer dump-autoload -v 看输出里有没有警告，再 grep -r "class App\YourClass" vendor/composer/ 确认类名是否进了 classmap。自动加载链上任何一环断开，都会表现为“类找不到”，而问题往往藏在最不起眼的斜杠或大小写里。
