ThinkPHP 8.0 是基于 PHP 8.0+ 重构的现代框架，要求 PHP 8.1+ 运行，路由、中间件、ORM、命名参数、OPcache/JIT 及模块化机制均发生重大变更，需按新规范适配。
ThinkPHP 8.0 不是 ThinkPHP 6 的简单迭代，而是基于 PHP 8.0+ 重构的现代框架——它要求你用 PHP 8.1+ 运行，否则核心特性（如构造函数属性提升、联合类型）会直接报错或失效。
为什么升级后路由不生效或中间件跳过
ThinkPHP 8.0 的路由系统彻底重写，不再兼容 TP6 的 Route::get() 链式调用风格。新路由注册必须通过闭包或控制器方法绑定，且默认启用「严格模式」：路径末尾斜杠 / 会被视为不同路由。
- 旧写法（TP6）：
Route::get('user/:id', 'index/User/read')→ 在 TP8 中会 404 - 新写法（TP8）：
Route::get('user/:id', [app\controller\Index::class, 'userRead'])或使用闭包 - 若需保留末尾斜杠兼容性，必须显式配置
'route_complete_match' => false到config/route.php - 中间件执行顺序也变了：TP8 默认按「全局 → 分组 → 路由级」叠加，且不自动继承父分组中间件，需手动用
->middleware()显式追加
模型返回 null 但代码没报错，怎么调试
这是 PHP 8.1+ 类型声明与 TP8 ORM 协同作用的结果：当你在模型方法中写了 public function getUser(int $id): ?array，TP8 的 think-orm 3.0 会在查不到数据时安静返回 null，而不会抛异常——这和 TP6 的 find() 行为一致，但配合强类型后更易被忽略。
- 检查是否启用了
strict_types=1（推荐开启，但需全项目统一） -
Db::name('user')->find($id)返回null是正常行为；但若你期望对象，应改用->findOrFail()显式中断 - 软删除字段（如
delete_time）现在默认参与查询过滤，若未设置该字段或值为null，find()也可能返回空，需确认数据状态
命名参数传参报错「Unknown named parameter」
TP8 控制器方法支持命名参数，但仅限于你**自己定义的方法**，框架内置方法（如 __construct()、initialize()）不接受命名参数调用。常见误用是试图在 URL 路由参数里用命名语法，比如 /user?id=123 然后想在方法里写 public function read(id: 123) —— 这完全无效。
立即学习“PHP免费学习笔记（深入）”；
- 命名参数只在 PHP 层调用时生效，例如：
$this->userRead(id: 123, name: 'foo') - 路由变量仍靠位置匹配，
read($id, $name)对应/read/123/foo - 若需从请求中提取命名式参数，应使用
input('id')或request()->param('id')，而非函数签名 - 构造函数属性提升（
public function __construct(public string $name, private int $age)）是类定义语法，和运行时传参无关
OPcache + JIT 开启后反而变慢
TP8 强依赖 OPcache，但 JIT 编译器不是开就完事。实测中，opcache.jit=1235 是最稳妥的配置，而 opcache.jit=off 或 opcache.jit_buffer_size 小于 64M 会导致 JIT 实际未启用，甚至因反复编译拖慢性能。
- 务必确认
opcache.enable_cli=1，否则命令行工具（如php think）无法受益于 JIT - 模板编译、ORM SQL 构建、容器解析这三类操作在 JIT 下提速最明显，但前提是这些代码被高频执行（如首页、列表页），冷门接口几乎无感
- 升级后首次访问慢是正常的：OPcache 需预热，建议部署后用脚本模拟 10 次关键路由请求，再测真实性能
- 若用 Swoole 或 RoadRunner，JIT 效果会打折扣，因其本身已做常驻进程优化
真正容易被忽略的点是：TP8 的「模块化」不是概念，而是强制约束——所有服务提供者（Service Provider）必须实现 register() 和 boot()，且不能在 register() 阶段访问尚未加载的组件，否则会触发循环依赖错误，这种问题在本地开发时可能不暴露，上线后才爆发。
