ThinkPHP中间件未生效的首要原因是handle()未返回Response实例，导致请求静默中断；需确保所有分支显式return，正确处理OPTIONS预检，并验证路由绑定与请求方法匹配。
中间件没生效？先确认是否返回了 Response 实例
ThinkPHP 中间件 handle() 方法必须返回 think\Response 实例，否则请求会静默中断，浏览器收不到任何响应，开发者也看不到错误——这不是“拦截失败”，而是根本没走完中间件链。
常见错误写法：if (!Auth::check()) { abort(403); } 看似没问题，但漏掉了 return $next($request) 的分支，函数末尾隐式返回 null，框架直接终止流程，不报错、不记录、不响应。
正确做法：
- 所有分支都显式
return：放行时return $next($request)，拦截时return json(['msg' => '无权限'])->code(403)或return abort(403) - 不要用
die()、exit()、echo，它们绕过响应生命周期，日志、缓存、CORS 头全失效 - 调试时可在
handle()开头加trace('auth middleware hit')，确认是否被调用
请求压根没走到中间件？查路由绑定和方法匹配
PUT/DELETE 等非 GET/POST 请求常被误认为“中间件不生效”，实际是路由根本没绑中间件，或路由定义方法与请求方法不匹配。
立即学习“PHP免费学习笔记（深入）”；
例如：Route::get('api/user', ...)->middleware('CheckAuth') 对 PUT 请求完全无效；Route::resource('user', ...) 默认包含 update（对应 PUT），但中间件需单独指定：->middleware(['CheckAuth'], ['update'])。
快速验证方法：
- 执行
php think route:list，检查目标 URL 的Method列是否包含你发的请求方法（如PUT） - 确认该行路由的
Middlewares列是否含你的中间件名（如CheckAuth） - 若用
Route::any()，必须显式声明方法：->method(['PUT', 'PATCH'])，否则默认只匹配 GET
OPTIONS 预检卡住导致“拦截没反应”
前端带 Authorization 或 Content-Type: application/json 发 PUT 时，浏览器先发 OPTIONS 请求。若中间件里写了 if (!$request->header('Authorization')) { abort(401); }，OPTIONS 就会被拦住——后续 PUT 根本发不出，你以为是 PUT 没被拦截，其实是预检就断了。
解决关键点：
- 在中间件开头加
if ($request->isOptions()) { return response('', 204); }，立即放行预检 - 确保
204响应包含完整头：Access-Control-Allow-Methods和Access-Control-Allow-Headers，且后者字段要和前端实际发送的一致（大小写敏感） - 若启用
credentials: true，Access-Control-Allow-Origin不能为*，必须动态读取$request->header('origin')并白名单校验
输出具体错误原因的实操建议
想让拦截失败时有明确提示，不能只靠 abort(403) 这种通用码。真实场景中，你需要区分是未登录、权限不足、还是 Token 过期。
推荐写法：
- 用
Auth::check()判断登录态，Auth::user()->can('edit-post')判断权限，失败时return json(['code' => 403, 'msg' => '权限不足'])->code(403) - Token 校验失败时，别只抛异常，
return json(['code' => 401, 'msg' => 'Token 已过期或无效'])->code(401) - 避免在中间件里查 DB 报错后裸露 SQL 或路径信息，生产环境统一用
abort(403)，开发环境可加trace($e->getMessage())辅助定位
最易被忽略的是：中间件里对 $request->param() 或 $request->body() 的调用，在 OPTIONS 请求中可能返回空或触发解析异常——务必先判断 !$request->isOptions() 再做业务解析。
