novalidate 属性仅对 <form> 有效，存在即禁用原生验证（如 required、email 格式等），不影响 JS 验证方法和 CSS 伪类；formnovalidate 用于单个提交按钮，优先级更高；服务端校验不可省略。
novalidate 属性加在 <form> 上才生效
很多人误以为给 <input> 或 <button> 加 novalidate 能绕过验证，其实它只对整个表单起作用。浏览器只检查 <form novalidate> 这个布尔属性是否存在——存在即跳过所有内置验证（比如 required、type="email"、pattern 等）。
常见错误现象：<input novalidate> 完全无效，提交时依然报错；<form novalidate="false"> 也不行，因为它是布尔属性，有就是真，没有就是假，不认字符串值。
-
<form novalidate>✅ 正确写法 -
<form novalidate="">✅ 等效写法（空字符串也表示存在） -
<form novalidate="false">❌ 不起作用 -
<input novalidate>❌ 属性被忽略
novalidate 不影响 JavaScript 的 checkValidity() 和 reportValidity()
加了 novalidate 后，用户点击提交按钮确实不会触发原生提示，但 JS 仍可主动调用验证方法。比如你用 fetch 手动提交前想做校验，form.checkValidity() 依然返回 false，form.reportValidity() 依然会弹出浏览器提示（除非你同时阻止了默认提交行为）。
使用场景：你想禁用原生 UI 提示，但保留 JS 控制权——比如统一用自定义气泡提示，或和服务端校验逻辑对齐。
立即学习“前端免费学习笔记（深入）”；
- 提交按钮需用
event.preventDefault()阻止默认行为，否则表单仍会按原生逻辑提交（即使没提示） -
novalidate不改变:valid/:invalidCSS 伪类的计算，样式照常响应输入状态 - 若需完全关闭验证逻辑（包括 JS 方法），只能手动移除
required、pattern等属性，或用 JS 动态 disable 表单控件
兼容性没问题，但要注意和 formnovalidate 混用的陷阱
novalidate 在所有现代浏览器中都支持（包括 IE10+），真正容易踩坑的是和 formnovalidate（注意多了一个 form 前缀）一起用。后者是按钮级属性，仅对单个提交按钮生效。
例如：<form novalidate><button type="submit">普通提交</button><button type="submit" formnovalidate>跳过验证提交</button></form> —— 这里第一个按钮仍受 novalidate 影响（即不验证），第二个按钮也明确跳过，看似冗余。但如果去掉 novalidate，只留 formnovalidate，那它只对那个按钮生效，其他提交方式（比如回车、JS submit()）仍会触发验证。
-
formnovalidate只作用于带它的那个<button>或<input type="submit"> - 如果表单有多个提交入口，又只想让其中某一个跳过验证，必须用
formnovalidate，不能只靠novalidate - 两者同时存在时，
formnovalidate对应按钮的行为优先级更高，但不会影响其他提交方式
服务端永远别信 novalidate
这个属性纯属客户端控制，不影响任何后端逻辑。用户禁用 JS、手动删掉 novalidate、用 curl 提交，甚至直接改 DOM，都能绕过它。所以它只适合做“用户体验降级”或“临时调试”，绝不能替代服务端校验。
容易被忽略的地方：有些开发者加了 novalidate 后忘了在 JS 提交逻辑里补上等价的字段检查，结果空数据直通后端；或者误以为它能屏蔽 XSS/SQL 注入风险——完全不能。
- 前端跳过验证 ≠ 数据可信，服务端仍需完整校验字段存在性、格式、长度、权限等
- 调试时临时加
novalidate很方便，但上线前务必确认是否真不需要原生提示，以及 JS 校验是否覆盖所有路径 - 如果表单逻辑复杂（如动态增删字段、条件必填），
novalidate反而会让问题更难定位，因为丢失了浏览器的即时反馈
