ThinkPHP表单验证默认静默失败（返回false而非异常），需手动判断返回值或启用failException；失败时应显式返回422状态码并适配batch/scene规则结构。
验证失败时 validate 方法不抛异常，而是返回 false
ThinkPHP 的表单验证默认走的是「静默失败」路径：调用 validate 后，失败不会触发异常，只返回 false，$this->error 存错误信息。很多人卡在这儿，以为没生效，其实是自己没检查返回值。
常见错误现象：validate 调用后页面没报错、也没跳转，数据却进了数据库——因为没判断返回结果就直接执行了后续逻辑。
- 必须手动判断
if (!$this->validate($data, $rule)) { ... } - 若想统一拦截，建议在控制器基类或中间件里封装一层校验逻辑，而不是每个方法都写重复的
if -
validate第三个参数可传true开启「失败抛异常」模式，但要注意这会中断流程，且异常类型是ValidateException，不是HttpException或BadRequestHttpException
要返回自定义 HTTP 状态码，得绕过默认的 validate 流程
ThinkPHP 默认验证失败时返回 200 + 错误信息数组（如 ['code'=>0,'msg'=>'...']），没法直接设 400/422。想返回 422 Unprocessable Entity，必须手动终止响应并设置状态码。
使用场景：前后端分离项目，前端依赖状态码做统一错误处理，不能只靠 code 字段。
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖
validate自动返回，改用Validate::make()实例化后调用check() - 失败时用
response()->code(422)->json([...])显式返回（ThinkPHP 6.0+） - 注意
response()是闭包函数，不是静态方法；旧版本（5.1）需用json([...])->code(422) - 示例：
if (!$validate->check($data)) { return json(['code' => 422, 'msg' => $validate->getError()])->code(422); }
ValidateException 异常不会自动设 422，需手动捕获并重写响应
即使你开了 validate(..., ..., true)，抛出的 ValidateException 仍会被框架默认异常处理器转成 500 或 200，不会变成 422。
性能影响小，但兼容性差：不捕获的话，前端收不到语义明确的状态码；捕获后又得额外维护异常处理分支。
- 在
app/exception/Handle.php的render方法里加判断：if ($e instanceof ValidateException) { return json(['code' => 422, 'msg' => $e->getMessage()])->code(422); } - 别直接 throw 新异常（比如
throw new HttpException(422, ...)），会丢失原始错误字段（如$e->getError()是数组，$e->getMessage()只是字符串） - ThinkPHP 6.1+ 支持在 validate 规则里用
failException配置，但底层仍是同个异常类，逃不开手动捕获这步
验证规则里的 scene 和 batch 会影响错误结构，进而影响前端取值
返回的错误信息格式取决于你怎么调用验证，而格式不对会导致前端解析失败——比如批量验证开启后，$validate->getError() 返回二维数组，但多数前端只 expect 一维 msg 字符串。
容易踩的坑：用了 batch 却没适配前端，结果提示显示为 [object Object]。
-
batch => true时，$validate->getError()是['field1' => 'xxx', 'field2' => 'yyy']，适合表单级提示 -
scene不影响状态码，但会影响规则加载范围；若 scene 没定义字段，该字段验证直接跳过，可能造成漏检 - 如果后端要返回结构化错误（如字段级 error map），建议统一用
batch => true+ 手动构造响应体，别依赖默认getError()
validate 写在事务里却没回滚——这些比状态码本身更难排查。 
