中间件与验证器在ThinkPHP中需手动桥接：必须通过容器获取验证器（如Validate::scene('add')->batch()->check($data)），在路由解析后、控制器执行前调用，取参用$request->param()，失败时根据isAjax()或accept头返回JSON或重定向，避免new实例导致上下文丢失。
中间件和验证器在 ThinkPHP 里不是自动联动的，必须手动桥接——验证器不进中间件就只是个静态类，中间件不调验证器就只做流程控制，两者脱钩会导致重复校验或漏校验。
中间件里怎么调用验证器
验证器不能靠 new 实例化后直接 ->check()，因为验证器依赖容器注入（如场景、消息、规则缓存），手动 new 会丢失上下文。正确方式是通过容器获取：
- 用
Validate::make()动态创建，传入规则数组和消息数组，适合简单、临时规则 - 用
app('validate')->rule($rules)->message($messages)->check($data)，更贴近原生写法 - 若已定义命名验证器（如
app\validate\User），推荐Validate::scene('add')->batch()->check($data)，支持场景 + 批量错误收集 - 注意：验证失败时不要直接
throw异常，中间件应统一返回 JSON 响应或重定向，例如：return json(['code' => 400, 'msg' => $validate->getError()])
验证时机必须卡在路由解析后、控制器执行前
中间件执行顺序决定能否拿到完整参数。常见错误是把验证逻辑放在「认证中间件」之前，结果 $request->param() 还没解析完，或表单数据被 input('post.') 误读为空。
-
$request->param()是最稳妥的取参方式，它已合并 GET/POST/PUT/PATCH 数据，且自动过滤空格 - 避免用
$request->post()，它不兼容 PUT/PATCH 请求体（如 axios 默认发的是 JSON） - 如果验证器需要文件上传字段，得先调
$request->file()并传给验证器的file规则，否则image或fileSize会跳过 - 对 RESTful 接口，建议在中间件开头加判断：
if (!in_array($request->method(), ['POST', 'PUT', 'DELETE'])) return $next($request);，避免 GET 请求误触发验证
全局中间件 vs 路由级中间件选哪个
全局注册验证中间件看似省事，但实际极易误伤——登录接口、验证码、健康检查等路径都会被拖进验证流程，导致 400 错误泛滥。
立即学习“PHP免费学习笔记（深入）”；
- 路由组绑定更可控：
Route::group(['middleware' => 'check.validate'], function () { ... })->except(['login', 'captcha', 'health']); -
except匹配的是路由名（Route::get('login', ...)->name('login')）或完整 URL 路径（如/api/v1/login），不是控制器方法名 - 若用注解路由（
@Middleware），需确保注解扫描已开启，且中间件别名已在config/middleware.php的alias中注册 - 多个验证中间件叠加时（如先验参、再验权限），注意它们在
middleware.php中的顺序：越靠前的越早执行，也越早能中断请求
验证失败后怎么处理响应格式
同一个中间件可能被浏览器页面、Vue 组件、小程序同时调用，硬编码 json() 或 view() 都会翻车。
- 优先看
$request->isAjax()：true 表示是 JS 发起的异步请求，返回 JSON 更安全 - 其次看
$request->header('accept')是否包含application/json，比isAjax()更底层、更可靠 - 兜底策略：非 JSON 请求走重定向（如
redirect('/login?from=' . urlencode($request->url()))），并附带提示闪存：$request->session()->flash('error', '参数错误') - 切忌在验证失败时调
halt()或die()，这会绕过框架的异常处理和日志记录
真正难的不是写验证逻辑，而是让验证器在中间件里拿到干净、完整、格式一致的数据；而最容易被忽略的，是验证失败后如何把错误信息以对方能理解的方式送回去——前端要 JSON 字段名，后台运营要可读提示，监控系统要结构化状态码。
