服务端验证失败时应返回何种响应？

首先明确几个核心结论：不要只返回状态码，必须返回具体字段错误提示；绕过客户端验证的请求不一定是恶意的，服务端验证是兜底但友好提示更重要。

一、为什么必须返回字段级错误提示？ #

客户端验证只是提升用户体验的第一层防护，完全依赖它是不现实的：

• 很多用户会出于隐私考虑禁用JavaScript，导致HTML验证直接失效
• 旧版浏览器可能不支持某些HTML5验证规则（比如input[type=number]的min属性）
• 用户可能通过开发者工具临时修改表单属性（比如把min="1"改成min="-100"），这可能只是好奇测试而非恶意操作
• 网络加载异常时，客户端验证脚本可能未正常加载完成

如果服务端只返回400/422而不说明具体错误，这些合法用户会完全摸不着头脑，不知道该怎么修正表单。正确的做法是：

• 服务端验证后返回结构化的错误信息（比如JSON格式），包含每个字段的错误描述
• 前端接收后将错误提示展示在对应字段下方，和客户端验证的提示风格保持一致

示例返回结构（JSON）：

{
  "errors": {
    "quantity": "请输入大于0的正整数",
    "price": "价格不能为0或负数"
  }
}

二、绕过客户端验证的请求是否属于恶意？ #

答案是不一定，大部分情况是合法场景：

• 如上面提到的禁用JS、浏览器兼容问题、用户临时测试
• 甚至可能是用户使用了自动化工具（比如浏览器插件）填充表单，不小心绕过了验证

当然确实存在恶意请求的可能（比如批量提交垃圾数据、尝试SQL注入或其他攻击），但不能把所有绕过客户端验证的请求都归为恶意。服务端要做的是：

1. 严格执行业务规则验证，不管请求来源
2. 对频繁触发验证失败的请求，结合IP、用户行为等维度判断是否为恶意，必要时触发限流或封禁
3. 对明显的攻击行为（比如注入特殊字符），可以返回更简洁的提示或直接拦截，但普通的规则违反还是要给友好提示

三、状态码的选择 #

• 400 Bad Request：适合请求格式完全错误的场景，比如JSON格式解析失败、请求参数缺失导致无法解析
• 422 Unprocessable Entity：更适合请求格式正确，但业务规则不满足的情况（比如Quantity为负、Price为0），这能更准确地告诉客户端和用户：请求能被理解，但不符合业务要求

补充实践建议 #

• 服务端验证规则必须和客户端完全对齐，避免出现“客户端通过验证，服务端却拒绝”的矛盾情况
• 错误提示要具体、易懂，避免模糊表述（比如用“请输入1-100之间的正整数”代替“数量无效”）
• 对于敏感操作（比如支付表单），可以在服务端增加额外的安全校验（比如验证码、请求签名），但普通表单还是优先保证用户体验

内容的提问来源于stack exchange，提问作者vikarjramun