novalidate仅禁用浏览器原生验证（required、type、pattern等）的自动拦截提交和UI提示，不影响JavaScript校验、reportValidity()、CSS伪类及ValidityState计算。
novalidate 属性到底禁用哪些验证
novalidate 是 <form></form> 标签的布尔属性，它只影响浏览器原生的表单验证行为——也就是 required、type="email"、pattern、min/max 等触发的弹窗提示和 checkValidity() 返回值。它**不阻止 JavaScript 手动调用 reportValidity()，也不影响你写的自定义校验逻辑。
常见误解是加了 novalidate 就“完全关掉所有验证”，其实只是绕过了 HTML5 自动拦截提交 + 内置 UI 提示这层。
- 表单提交时，浏览器不再自动检查
required字段是否为空 -
input.reportValidity()仍会返回false，且仍会触发invalid事件（除非你同时阻止了） -
:valid/:invalidCSS 伪类依然生效（样式不受novalidate影响）
什么时候该加 novalidate，什么时候不该加
加 novalidate 的典型场景是：你要用 JS 全权控制验证流程（比如统一收集错误、定制提示位置、联动异步校验），又不想被浏览器默认的红色边框+气泡打断体验。
不该加的情况包括：仅想关闭某一个字段的验证（这时应改用 formnovalidate 在提交按钮上）、或只是懒得写 JS 验证却误以为加了它就“安全了”——后端仍必须做校验，前端跳过验证不等于数据可信。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- ✅ 适合：
<form novalidate></form>+ 全手动 JS 校验 + 自定义错误渲染 - ❌ 不适合：没写任何 JS 验证逻辑，只加
novalidate就上线 - ⚠️ 注意：
formnovalidate是按钮级属性，可单独让某个<button type="submit"></button>跳过验证，和novalidate作用域不同
novalidate 和 checkValidity() 的关系
即使设置了 novalidate，form.checkValidity() 依然返回布尔值，input.validity.valid 也照常计算。区别只在「提交是否被浏览器拦截」。
也就是说，你可以放心在提交回调里调用 if (!form.checkValidity()) { form.reportValidity(); return; }，它不会和 novalidate 冲突——novalidate 只是把“自动调用”这一步拿掉了，API 本身完好无损。
-
novalidate不改变ValidityState对象的任何字段 -
reportValidity()仍会显示浏览器原生提示（除非被 CSS 或event.preventDefault()拦截） - 若你用
addEventListener('submit', e => { e.preventDefault(); ... })，那novalidate实际上已无意义——因为提交早被你拦下了
容易被忽略的兼容性和副作用
novalidate 是 HTML5 标准属性，所有现代浏览器都支持，但老版本 IE（≤9）会忽略它，反而可能意外触发验证——不过这类环境现在基本不用考虑。
真正容易踩的坑是样式和可访问性：禁用原生验证后，很多开发者忘了给无效字段添加 aria-invalid="true" 和 aria-describedby，导致屏幕阅读器无法感知错误，违反 WCAG。
- 别只靠视觉样式（如红边框）提示错误，必须同步更新 ARIA 属性
- 如果用了
setCustomValidity('')清空错误，记得再调一次reportValidity()或手动更新状态 - 服务端返回校验失败时，前端重新填充表单后，要主动调用
input.setCustomValidity('')重置状态，否则后续checkValidity()可能持续返回false
