📚 课程目录第3章前端校验 vs 后端校验

3. 前端校验 vs 后端校验：各自优缺点、适用场景、如何协同工作

做数据校验这么多年，我见过太多团队在前端和后端之间「二选一」。其实这是个伪命题。你想想看，一个表单提交，前端帮你拦住了 80% 的明显错误，后端再兜住剩下的 20% 恶意或异常数据——这才是正经做法。

但问题来了：哪些校验放前端？哪些必须放后端？两边都写一遍是不是重复劳动？

别急，咱们一层层拆开看。

3.1 前端校验：快，但别信它

前端校验的核心价值就一个字——快。用户刚输完手机号，还没点提交，页面就告诉你「格式不对」。这种即时反馈，用户体验是最好的。

核心原则：前端校验只负责「用户体验」，不负责「数据安全」。任何前端校验都可以被绕过，所以永远不要在前端做安全相关的校验。

优点

即时反馈：用户不用等网络往返，输入完就能看到错误提示。
减轻服务器压力：无效请求在浏览器端就被拦截了，后端少处理很多垃圾数据。
交互更丰富：可以做实时字数统计、密码强度指示器、联动校验（比如选择省份后自动校验城市）。

缺点

完全不可信：用户可以直接关掉 JavaScript，或者用 Postman 直接发请求。前端校验形同虚设。
逻辑容易被篡改：前端代码是公开的，稍微懂点技术的人都能改。
能力有限：无法做数据库唯一性校验、无法验证业务状态（比如订单是否已支付）。

适用场景

必填项检查（字段是否为空）
格式校验（邮箱、手机号、身份证号格式）
长度限制（用户名 2-20 个字符）
联动校验（密码和确认密码是否一致）
UI 层面的友好提示（输入框变红、显示错误文案）

3.2 后端校验：慢，但它是最后一道防线

后端校验才是真正的「守门员」。我习惯把它分成两层：基础校验和业务校验。

基础校验负责「数据对不对」，业务校验负责「数据能不能用」。举个例子：用户提交一个订单退款请求，基础校验检查退款金额是不是正数，业务校验检查这个订单是不是已经退款过了。

优点

可信：代码跑在自己的服务器上，用户改不了。
能做复杂校验：查数据库、调外部接口、验证业务状态，这些前端做不了。
统一安全策略：所有入口（Web、App、API）都走同一套校验逻辑，不会漏掉。

缺点

响应慢：用户必须等请求发到服务器、校验完、再返回结果，至少几百毫秒。
消耗服务器资源：每个无效请求都要占用 CPU 和数据库连接。
错误反馈不够友好：通常只能返回一个错误码和一段文字，没法像前端那样在输入框旁边实时标红。

适用场景

所有安全相关的校验（权限、身份认证）
数据完整性校验（外键约束、唯一索引）
业务规则校验（订单状态流转、库存扣减）
跨字段复杂校验（总金额 = 单价 × 数量）
数据持久化前的最后把关

我曾经踩过的坑：有个项目只做了前端校验，后端直接 insert。结果用户用 Postman 发了个负数金额的订单，数据库里多了一条「-500 元」的记录。对账的时候查了三天才找到原因。从那以后，我所有项目的后端校验都是强制性的，前端校验只是锦上添花。

3.3 前后端校验对比一览

对比维度	前端校验	后端校验
响应速度	毫秒级（本地执行）	百毫秒级（网络+处理）
可信度	低（可被绕过）	高（服务器执行）
复杂度上限	低（无法访问数据库）	高（可调用任何服务）
用户体验	好（即时反馈）	一般（需等待）
维护成本	中（需与后端同步规则）	高（需覆盖所有场景）
安全防护	无	强（最后一道防线）

3.4 如何协同工作？——分层校验策略

说白了，前后端校验不是「二选一」，而是「分层防守」。我个人习惯用三层模型：

第一层：前端即时校验——拦截明显错误，提升用户体验。
第二层：后端基础校验——验证数据格式、类型、长度、非空等基础规则。
第三层：后端业务校验——验证业务状态、数据一致性、权限等。

这里有个关键点：前端和后端不要写两套独立的校验规则。我见过最痛苦的项目，前端改了校验规则，后端忘了同步，结果前端说「通过」，后端说「不通过」，用户卡在中间。

我的建议：把校验规则定义成一份「共享规则文件」（JSON 或 YAML 格式），前端和后端都从这份文件生成校验代码。这样改一处，两边同步更新。很多框架（比如 Joi、Yup、Zod）都支持这种模式。

协同工作流程图

3.5 实际项目中的协同模式

我参与过的几个大型项目，最终都沉淀出了类似的模式。这里分享一个我比较推崇的做法：

规则共享 + 分层执行

// 共享规则定义（rules.json）
{
  "username": {
    "required": true,
    "minLength": 2,
    "maxLength": 20,
    "pattern": "^[a-zA-Z0-9_]+$"
  },
  "email": {
    "required": true,
    "format": "email"
  },
  "age": {
    "required": false,
    "type": "integer",
    "min": 0,
    "max": 150
  }
}

前端拿到这份 JSON，生成表单校验规则。后端也拿这份 JSON，生成接口校验中间件。两边用的是同一份数据，不会出现规则不一致的情况。

关键原则：前端只做「格式校验」和「必填校验」，后端做「格式校验」+「业务校验」+「安全校验」。前端校验通过后，后端必须重新校验所有规则——不要相信前端传来的任何数据。

错误处理协同

前端校验失败：直接在输入框下方显示红色提示文案。

后端校验失败：返回统一的错误结构，前端根据错误字段名定位到对应的输入框，显示后端返回的错误信息。

// 后端统一错误响应格式
{
  "code": 422,
  "message": "数据校验失败",
  "errors": [
    { "field": "email", "message": "该邮箱已被注册" },
    { "field": "age", "message": "年龄必须在 0-150 之间" }
  ]
}

前端拿到这个响应后，遍历 errors 数组，把每个字段的错误信息渲染到对应的输入框下方。这样用户看到的效果和前端校验一样——即时、精准、友好。

一个小技巧：后端校验的错误信息可以比前端更具体。比如前端只提示「邮箱格式错误」，后端可以提示「该邮箱已被注册」或「该邮箱已被禁用」。因为后端能访问数据库，知道更多上下文。

3.6 避坑指南

不要在前端做唯一性校验：比如「用户名是否已被注册」。这种校验必须查数据库，前端查不了。即使用 AJAX 查了，也存在并发问题。
不要在后端只做基础校验：我见过有人把后端校验写成「只要非空就通过」，结果业务逻辑全在数据库层报错。后端校验要覆盖所有业务规则。
不要忽略前端校验的维护成本：规则变了，前端和后端都要改。如果没做好共享规则，很容易出现「前端改了后端没改」的情况。
不要在前端校验通过后跳过后端校验：这个我强调过很多次了——前端校验只是用户体验，后端校验才是数据安全。

嗯，前后端校验的协同，说白了就是「前端负责快，后端负责稳」。两者配合好了，用户体验好，数据也安全。配合不好，要么用户被烦死，要么数据库被搞乱。