required 仅在客户端拦截空提交，服务端必须独立实现等价空值校验逻辑，且需按字段类型细化判定（如trim、select默认值、checkbox未勾选等），不可依赖前端任何校验结果。
Required 属性本身不构成服务端校验，它只在客户端提交时做最基础的空值拦截；服务端必须独立实现等价逻辑，不能信任任何前端传来的 required 状态。
required 校验失败时，服务端收不到请求
浏览器原生行为是：只要任一 required 字段为空，submit 事件会被阻断，表单根本不会发出 HTTP 请求。这意味着服务端压根看不到这次“无效提交”——它不是被拒绝，而是被前端静默拦下了。
所以你不会在后端日志里看到“空用户名”的报错，只会发现某些用户卡在表单页没跳转。排查时别急着查后端接口，先确认前端是否真发出了请求（看 Network 面板有没有对应 fetch/XHR）。
- 用
form.submit()JS 调用会绕过 required 校验，必须配合form.checkValidity()手动判断 - 用
fetch()或axios提交表单数据时，required 完全失效，所有字段都得靠 JS 自行校验后再发 - 移动端 WebView（如旧版微信内置浏览器）可能忽略 required，导致空数据直达服务端
服务端校验必须复现 required 的判定逻辑
服务端不能简单判 value === null || value === undefined，因为 required 的语义是“用户未提供有效输入”，而这个“有效”在不同字段类型下含义不同：
-
<input type="text">：需按value.trim() === ""判定，空格、制表符、零宽字符（\u200B）都算空 -
<select></select>：检查选中项的value是否为非空字符串；若首项是<option value="">请选择</option>，且被默认选中，则视为未填写 -
<input type="checkbox">：未勾选即为缺失，但注意多选同名 checkbox 时，服务端收到的是数组，空数组等价于未勾选 -
<input type="file">：服务端应检查req.files（Express）或request.FILES（Django）是否存在对应 key，而非只看字段名是否在req.body中
绕过前端的 curl、Postman 或禁用 JS 后手动提交，都会让这些边界情况暴露出来。
前后端空值定义不一致会导致体验断裂
比如前端用 required + type="email"，用户填了 "test@.com"，浏览器认为“已填写”（通过 required），但格式校验失败；服务端若只校验空值，就会接受这个非法邮箱。
更隐蔽的问题是 placeholder 和 readonly 字段：它们不影响 required 判定，但用户可能误以为“有默认值就不用填”。服务端若对 readonly 字段不做特殊处理（比如跳过校验或强制覆盖），就可能把前端伪造的值当真。
- 服务端不要依赖前端传来的任何“校验结果”字段（如
is_valid） - 对所有
required字段，服务端必须执行与浏览器相同的空值判定，并额外叠加业务规则（如邮箱正则、手机号长度） - 错误响应要返回具体字段名和错误类型（
{"field": "email", "error": "empty"}），方便前端精准标红，而不是笼统返回“参数错误”
联动设计中最容易被忽略的点
不是“怎么写校验逻辑”，而是“谁来触发校验时机”。前端 required 只响应 submit 事件；服务端校验却发生在每次请求入口。如果前端用按钮 type="button" + fetch() 提交，那 required 就彻底失效，而服务端又没配好空值拦截，空数据就直接入库了。
真正需要对齐的，是字段语义的生命周期：从用户聚焦输入框开始，到服务端落库结束，每个环节都要明确“这个字段在此刻是否允许为空”。required 只覆盖其中一环，漏掉任意一环，整个联动就断了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
