thinkphp 6.0 中间件注册需在应用层显式绑定，handle() 方法允许返回 null 但须显式兜底，路由绑定取消分组别名仅支持类名或实例，异常中间件须实现 handleinterface 并返回 response 实例。
中间件注册方式从全局配置移到应用层
5.1 中间件靠 app/middleware.php 全局数组注册，6.0 废掉了这个文件；现在必须在应用初始化阶段显式绑定，否则中间件根本不生效。
常见错误现象：升级后中间件完全不触发，日志无任何调用痕迹，路由和控制器照常执行——其实是压根没注册进去。
- 5.1 写法：
return [App\Middleware\CheckAuth::class]; - 6.0 正确位置：在
app/provider.php或app/bootstrap.php中调用app()->middleware->add()，或更推荐在app/middleware.php（新用途）中返回闭包/类数组，再由app()->middleware->import()导入 - 注意兼容性：6.0 的
add()方法第二个参数支持'before'/'after'，但若中间件含except白名单逻辑，需手动在handle()里判断，框架不再自动跳过
handle() 方法签名与返回值语义变化
5.1 中间件 handle() 必须返回 Response 实例，否则报错；6.0 改为允许返回 null 或原始请求/响应对象，框架会自动包装，但这也导致很多老代码在 6.0 下静默失效。
典型场景：你在 5.1 里写了 return $next($request);，到了 6.0 可能直接中断流程，因为 $next() 返回的是 think\Response，而你没做任何处理就 return 了——框架认为这是最终响应，后续中间件和控制器全被跳过。
- 6.0 推荐写法：
return $next($request) ?: $this->fail('missing response');（显式兜底） - 不要依赖隐式返回：
$next($request)在异常路径下可能返回null，尤其配合try/catch时 - 性能影响：6.0 对返回值类型检查更松，但若中间件链中某处返回了非
think\Response实例（比如原生Illuminate\Http\Response），会抛出InvalidArgumentException
中间件分组与路由绑定语法不兼容
5.1 用 middleware 数组键名做分组别名（如 'auth' => [CheckAuth::class]），然后在路由里写 ->middleware('auth')；6.0 彻底取消分组别名映射机制，路由绑定只认中间件类名、实例或闭包。
错误现象：路由定义里写 ->middleware('auth')，启动时报 Middleware not found: auth，即使 app/middleware.php 里还留着旧分组配置也没用。
- 迁移做法：把所有路由中的字符串中间件名，替换成完整类名
App\Middleware\CheckAuth::class或提前实例化好的对象 - 如果想保留语义化名称，得自己实现中间件解析器，在
app/provider.php中重写think\Pipeline的解析逻辑（不推荐，维护成本高） - 注意：6.0 路由中间件支持数组嵌套写法，如
->middleware([CheckAuth::class, LogRequest::class])，但不支持混合字符串+类名
异常中间件的触发时机和参数结构变了
5.1 异常中间件接收两个参数：$request 和 $e（异常对象）；6.0 统一为单参数 $e，且要求中间件类必须实现 think\exception\HandleInterface，否则不会被识别为异常中间件。
最容易被忽略的坑：升级后 500 页面还是显示默认模板，自定义异常页不生效——不是模板路径错了，是中间件根本没进到异常处理流程里。
- 6.0 必须确保类声明 implements
think\exception\HandleInterface，并实现render()方法 -
render()方法里不能再直接 echo 或 exit，必须返回think\Response实例 - 兼容提示：6.0 默认异常中间件已内置 JSON 格式化逻辑，若你原来在 5.1 里手动
json_encode()，现在可能重复序列化，导致双层引号
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
