Laravel如何做API请求体JSON校验_Laravel验证结构合法性【操作】-Laravel-PHP中文网

laravel 的 validate 方法可直接校验 json 请求体，需确保 content-type 为 application/json；嵌套字段用 'user.name' 语法，数组根节点需先 toarray()；复杂条件校验建议分步验证；错误定位优先查原始请求内容与响应结构定制。

laravel如何做api请求体json校验_laravel验证结构合法性【操作】

直接用 Laravel 自带的 validate 方法就能校验 JSON 请求体，前提是请求头带 Content-Type: application/json 且数据已正确解析。Laravel 会自动把 JSON body 解成 PHP 数组，和表单提交一样走验证流程。

常见错误现象：422 Unprocessable Content 返回但字段名对不上，或者 required 校验总失败——大概率是前端没发 JSON，或发了但没设对 Content-Type，导致 Laravel 当作空请求处理。

确保前端发送时设置 headers: { 'Content-Type': 'application/json' }
后端不需要手动 json_decode($request->getContent())，Laravel 已帮你做了
验证规则写法和表单一致，比如 ['user.name' => 'required|string'] 可校验嵌套字段
如果 JSON 是数组根节点（如 [{"id":1}, {"id":2}]），需先在控制器里用 $request->toArray() 转换再验证，validate 默认只接受对象型 JSON

当 JSON 结构复杂（比如含动态字段、条件必填项），光靠基础规则容易漏检。重点不是“能不能写”，而是规则怎么贴合真实数据形状。

使用场景：用户提交一个 config 对象，其中 type 为 "database" 时，host 和 port 必须存在；为 "api" 时则要校验 endpoint。

Laravel Creem Agent

Creem 支付商店助理 — 查询订阅、客户、交易、产品，执行心跳检查，管理本地 Laravel支付商店。

下载

用 'config.*.type' => 'required|in:database,api' 先约束类型值
'config.*.host' => 'required_if:config.*.type,database' 不生效——Laravel 不支持通配符交叉引用，得改用自定义规则或分步验证
更稳的做法：提取子数组，单独验证，例如 $request->validate(['config' => 'required|array']) 后，对 $request->input('config') 再调一次 Validator::make(...)
array 规则必须显式声明，否则 {} 或 null 会被当成字符串通过

这不是 Laravel 报的错，是前端 JS JSON.parse() 失败的提示，说明发到后端的压根不是合法 JSON。Laravel 还没走到验证那步就卡在请求解析阶段，日志里可能只看到空参数或 500。

检查 Network 面板里的 Request Payload 是否为纯 JSON 字符串（无额外引号、无 console.log 输出混入）
Node.js 前端常用 JSON.stringify(data) 但忘了 headers，导致 Laravel 当作普通 form-data 解析，body 变成字符串 "{...}"，而非数组
Laravel 日志里搜 InvalidArgumentException: Unable to parse body 或看 $request->json()->all() 是否为空数组
临时加一行 Log::info($request->getContent()); 看原始输入，比猜快得多

Laravel 默认的 422 响应格式是 {"message":"The given data was invalid.","errors":{"field":["error msg"]}}，但很多前端期望扁平结构如 {"field":"error msg"} 或带状态码字段。

性能影响不大，但兼容性差——特别是对接老系统或小程序时，字段名/嵌套层级错一点就解析失败。

不要重写整个异常渲染器，只需在 app/Exceptions/Handler.php 的 render 方法里拦截 ValidationException
用 $exception->validator->errors()->first() 或 ->getMessages() 提取原始错误，再组装新结构
注意：修改后所有 API 验证都会走这个逻辑，包括 FormRequest，别漏掉 failedValidation 方法的覆盖
如果只针对某几个接口，更轻量的做法是在控制器里 try/catch ValidateException，手动 return 响应