前端提交表单，接口返回的不是200也不是400，而是422 Unprocessable Entity，提示里还带一串字段名。第一次遇到容易懵：400和422不是一回事吗？

422到底代表什么

422的含义是「请求格式没问题，但内容语义过不了校验」。服务器能正常解析发过去的数据，只是数据本身不合格：字段缺了、邮箱格式不对、数量填了负数。400更偏「请求本身有问题」，比如JSON写坏了、根本没带参数。多数框架在参数校验这一层，校验不过就回422。

HTTP 422 状态码最早出自WebDAV扩展，也就是RFC 4918，后来被Laravel、Rails这类框架广泛用在表单和模型校验场景。看到它，基本可以确定是后端校验逻辑拦下了请求，不是网络问题。

常见的触发场景

  • 必填字段没传，比如注册接口少了mobile参数
  • 格式不对，邮箱少了@，手机号多打了一位
  • 业务规则不过，密码长度不够，库存数量超出上限
  • 类型错了，接口要数字，传过去的却是字符串

按这三步排查

第一步看响应体，规范的接口会在422响应里带errors字段，写明哪个字段、什么原因，Postman里点开Body标签看返回，比光看状态码有用。第二步对照接口文档，逐个核对参数名、类型、必填项，参数名大小写不一样也会中招。第三步检查Content-Type，JSON接口要用application/json，用表单格式发过去，后端解析不到参数，同样报422。

返回体大致长这样：

HTTP/1.1 422 Unprocessable Entity | errors: mobile=手机号格式不正确, password=长度至少8位

和400、401、403的区别

粗略记：400是请求没法解析，401是没登录，403是没权限，422是看得懂但数据不合规。分清属于哪一类，排查方向才不会跑偏。

实际判断：遇到422不用怀疑服务器故障，重点核对请求体，把errors里列的字段逐个改对，多数情况就能通。