Class 'think\App' not found 是自动加载失败的典型表现，源于命名空间或路径错误、composer autoload未更新、大小写敏感、BOM/空行干扰及Nginx PATH_INFO配置缺失等环境差异问题。
报错 Class 'think\App' not found 怎么快速定位
这是自动加载失败的典型表现，不是类写错了，而是命名空间或文件路径没对上。
常见错误现象：框架刚安装完就报这个错；或者从其他项目复制代码后突然出现。
-
composer dump-autoload必须执行，尤其改过composer.json或新增了自定义类目录 - 检查
app/下的类是否用了正确的命名空间，比如控制器必须是app\controller\Index，不能写成app\controller\index（Linux 下大小写敏感） - 确认
vendor/composer/autoload_classmap.php里有没有生成对应类的映射 —— 没有就说明composer install或dump-autoload没生效 - ThinkPHP 6+ 默认关闭
__autoload回退机制，别指望靠手动 require 补救
Db::table('user')->find() 返回 null 但数据明明存在
不是 SQL 写错了，大概率是主键字段名不匹配。
使用场景：用 find() 查单条、select() 查多条时，底层会默认按 id 字段查询 —— 如果你的表主键叫 uid 或 user_id，它就查不到。
立即学习“PHP免费学习笔记（深入）”；
- 显式指定主键：
Db::name('user')->pk('uid')->find(123) - 更稳妥的方式是用模型（
UserModel），并在模型里设置protected $pk = 'uid'; - 注意
Db::table()是无模型操作，不读取模型配置，也不走模型的主键定义 - 如果表没有主键，
find()会直接返回第一条，容易误判为“查到了”，实际逻辑已错
开启调试模式后页面空白，但日志里也没报错
通常是输出被提前触发，导致 header 无法发送，进而引发后续异常静默。
性能影响不大，但排查成本很高 —— 因为错误被 PHP 的 output buffering 机制吞掉了。
- 检查所有
config/下的 PHP 文件末尾有没有空行或 UTF-8 BOM（特别是 Windows 编辑器保存时容易带 BOM） - 确认
runtime/目录可写，否则日志写不进去，debug模式下连错误页面都渲染不出来 - 在入口文件
public/index.php最开头加ob_start();，再运行看是否报出 “headers already sent” - ThinkPHP 6.1+ 对 BOM 更敏感，建议用 VS Code 或 Sublime 以 UTF-8 无 BOM 格式保存配置文件
Route::rule('test', 'index/index/test') 访问 404
路由注册了，但没生效 —— 大概率是没进对路由分组，或规则被前置规则拦截。
兼容性影响明显：本地开发可能正常，部署到 Nginx 后就 404，因为服务器重写规则没配好。
- 确认是否在
route/app.php里注册，而不是只写在闭包里（如route/route.php中未被加载） - 检查是否开启了强制 HTTPS 或子目录部署，此时需要在
config/app.php中设置'app_subpath' => '/subdir/' - Nginx 需要正确转发 PATH_INFO：
fastcgi_param PATH_INFO $fastcgi_path_info;，漏掉这句会导致路由解析失败 - 用
php think route:list命令查看当前生效的全部路由，确认你的规则是否出现在列表中
复杂点往往藏在环境差异里：开发机的 Apache 自动处理 PATH_INFO，Nginx 不处理；Windows 不区分文件名大小写，Linux 区分；Composer 自动加载缓存没刷新，类就永远找不到。这些地方一漏，错误就卡在“看起来该有的都有”的假象里。
