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，它就查不到。

• 显式指定主键：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 自动加载缓存没刷新，类就永远找不到。这些地方一漏，错误就卡在“看起来该有的都有”的假象里。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！