novalidate仅禁用浏览器原生表单校验，无法阻止js发起的fetch等请求；后端必须校验，前端只负责体验优化与预检。
HTML5表单验证不能靠前端禁用
直接说结论：novalidate 属性只能关闭浏览器原生校验提示，但无法阻止用户用 fetch 或 XMLHttpRequest 绕过表单提交逻辑。所有“禁用校验以绕过”的想法，本质上是把安全责任推给前端——这在任何生产环境都不可行。
为什么 novalidate 不等于“禁用校验逻辑”
novalidate 仅影响 <form></form> 元素的默认提交行为：它让浏览器跳过 required、type="email" 等内置校验，不弹红框、不阻断 submit。但它对 JS 发起的请求完全无感。
- 用户仍可打开控制台，执行
fetch("/api/submit", { method: "POST", body: JSON.stringify({ email: "xxx" }) }) - 后端若没做校验，就会照单接收非法数据
-
novalidate常用于自定义校验场景（比如用 JS +setCustomValidity()），不是为“跳过校验”而设
真正该做的：后端必须校验，前端只负责体验
校验逻辑必须落在服务端，前端只承担三件事：提示友好、减少无效请求、配合 UX 流程。例如：
- 用
checkValidity()在 JS 提交前做一次快速预检，避免明显错误发到后端 - 提交时禁用按钮 + 显示 loading，防止重复点击
- 后端返回
400 Bad Request时，把错误字段映射回对应<input>的setCustomValidity("邮箱格式错误")并触发reportValidity()
示例片段：
form.addEventListener("submit", async e => {
e.preventDefault();
if (!form.checkValidity()) return;
const res = await fetch("/api/submit", {
method: "POST",
body: new FormData(form)
});
if (res.status === 400) {
const err = await res.json();
Object.entries(err).forEach(([field, msg]) => {
form[field]?.setCustomValidity(msg);
form[field]?.reportValidity();
});
}
});
容易被忽略的关键点
很多人以为“关掉 HTML5 校验就万事大吉”，其实最危险的是：后端校验缺失 + 前端未做 Content-Type 或 CORS 防御，导致任意 origin 都能 POST 数据。真实攻击链从来不是“绕过表单”，而是直接调用 API 接口——所以 novalidate 和 fetch 之间根本不存在“绕开”关系，只有“是否本就该校验”的认知偏差。
立即学习“前端免费学习笔记（深入）”；
