ClassNotFoundException 需检查类文件存在性、命名空间匹配、composer autoload 配置，并清空 runtime/container/ 与 cache/ 缓存。
报错信息里出现 ClassNotFoundException 怎么快速定位
ThinkPHP 升级后最常见的就是类找不到，尤其从 5.1 升到 6.x 或 8.x 时，ClassNotFoundException 频繁弹出。这不是 autoload 失败那么简单，而是命名空间、目录结构、自动加载配置全变了。
先别急着改代码，直接看错误堆栈最顶上那行——它会明确告诉你哪个 class 没加载成功，比如 appcommonmodelUser。这时候要立刻检查三件事：
-
app/common/model/User.php文件是否存在，且首行namespace appcommonmodel;是否与路径严格匹配（注意大小写） - 确认
composer.json里是否还残留旧的 autoload 配置，比如"psr-4": {"app\": "app/"}—— TP6+ 要求用thinkphp自带的加载器，不应再手动配psr-4 - 执行
composer dump-autoload -o，但更关键的是删掉runtime/container/和runtime/cache/，否则旧容器缓存会干扰类解析
Db::name('user')->select() 报 Call to undefined method
这是典型的门面（Facade）或查询构建器用法失效。TP6 开始把 Db 从全局静态门面改为依赖注入式调用，Db::name() 在默认配置下已不可用，除非你显式启用了门面支持。
解决方法分两步走：
立即学习“PHP免费学习笔记（深入）”；
- 如果坚持用静态调用，确保
config/app.php中'use_facade' => true已开启，并且composer require topthink/think-facade已安装 - 更推荐的方式是改用依赖注入：在控制器方法参数中声明
hink acadeDb $db，或直接使用hinkDb::name('user')->select()（注意是hinkDb，不是裸Db） - 特别注意：TP8 移除了
hinkDb类，统一用hink acadeDb，若升级到 TP8 还沿用hinkDb就会直接报错
日志里反复出现 SQLSTATE[HY000] [2002] Connection refused 却能正常访问首页
这说明数据库连接失败发生在日志写入环节，而非业务逻辑。TP 升级后默认启用「日志驱动异步写入」，而新版本的 log 配置可能仍指向 MySQL 驱动，但数据库连接尚未初始化完成，导致日志系统自己连不上库，形成死循环。
快速验证和修复方式如下：
- 打开
config/log.php，检查'default' => 'file'是否生效；如果误设为'database'，哪怕只有一处日志通道用了 DB 驱动，也会触发该错误 - 搜索整个项目，确认没有在
common.php或服务提供者里提前调用Db::connect()—— 日志初始化早于数据库服务注册，此时任何 Db 调用都会失败 - 临时把
log.level改成'error'，观察是否还报连接错误；如果消失，基本可断定是 debug 级别 SQL 日志试图写库导致
升级后接口响应变慢，debug 面板显示大量 thinkContainer::make
这不是 bug，是 TP6+ 引入的「延迟实例化」机制在起作用。每次请求都重新解析服务容器，尤其当大量使用 app()->make() 或未绑定单例时，性能损耗明显。
优化重点不在代码逻辑，而在容器注册方式：
- 检查
app/provider.php或服务提供者中，是否对高频使用的类（如thinkCache、thinkLog）做了$this->app->singleton()绑定；没绑定就等于每次make都 new 一次 - 避免在中间件或控制器里频繁调用
app()->make(XXX::class)，改用构造函数注入，框架会自动处理生命周期 - TP8 默认关闭了容器反射缓存，若项目有大量自定义服务，需手动开启
'container_cache' => true并确保runtime/container/可写
升级不是替换几个文件就能完事的事，类加载路径、服务注册时机、日志输出阶段这些隐性依赖链，才是最容易卡住人的地方。
