禁用 HTML5 原生表单验证最可靠的方式是在 <form> 上添加 novalidate 属性，它彻底禁用默认弹窗和提交拦截但保留 validity 状态供 JS 读取；另一种是结合 event.preventDefault() 与手动校验，但仍需 novalidate 配合，否则原生提示仍会触发。
禁用 HTML5 原生表单验证的两种可靠方式
想让自定义 JS 验证逻辑完全接管，必须先关掉浏览器默认的 required、type="email" 等触发的弹窗和提交拦截。最直接有效的是在 <form> 上加 novalidate 属性——它会彻底禁用所有原生验证反馈（包括 checkValidity() 的 UI 行为），但保留 validity 对象供你读取状态。
另一种是动态控制：给表单元素设 formnovalidate（仅对提交按钮生效），或在 JS 中调用 event.preventDefault() 并手动调用 form.checkValidity() 判断，但此时仍需配合 novalidate，否则点击提交时浏览器仍会弹出原生提示。
-
novalidate是布尔属性，写成novalidate=""或单纯novalidate都行 - 只加在
<form>上即可，不用每个 input 都加 - 加了之后
input.reportValidity()依然能触发原生 UI，如需彻底屏蔽，得额外监听invalid事件并preventDefault()
为什么 setCustomValidity("") 不能替代 novalidate
setCustomValidity("") 只是把当前字段的自定义错误清空，并不阻止其他原生规则（比如 type="email" 格式不符时仍会报错）。它本质是往 validity.customError 写值，而 validity.typeMismatch、validity.valueMissing 等仍可能为 true，导致 checkValidity() 返回 false。
常见误操作：只对某个 input 调用 setCustomValidity("") 就以为“禁用了验证”，结果提交时还是被拦住——因为浏览器检查的是整个表单的综合 validity 状态，不是单看 customError。
用于端到端视频本地化流程的轻量编排器，路由至四个专注子技能——/wjs-transcribing-audio、/wjs-translating-subtitles...
立即学习“前端免费学习笔记（深入）”；
- 必须配合
novalidate才能让自定义逻辑成为唯一决策者 -
setCustomValidity("错误信息")适合补充业务规则（如“用户名已存在”），不是用来覆盖原生校验 - 每次修改输入后，记得重置：先
setCustomValidity("")，再根据你的逻辑决定是否设新错误
自定义验证触发时机与原生事件的冲突点
原生验证默认在表单提交时触发，但用户更希望实时反馈（比如输完邮箱立刻标红）。这时若监听 input 或 blur，要小心和 invalid 事件打架——比如你刚在 blur 里设了 setCustomValidity("格式错误")，浏览器紧接着发 invalid 事件，又可能触发你自己的错误提示逻辑两次。
- 推荐统一用
addEventListener("input", handler)实时校验，避免依赖原生invalid - 如果必须监听
invalid，务必在 handler 里event.preventDefault()，否则会叠加原生弹窗 - 提交时用
form.addEventListener("submit", e => { e.preventDefault(); yourValidate(); })，确保流程完全可控
兼容性与移动端特殊行为
Chrome / Firefox / Safari 桌面端对 novalidate 支持良好，但 iOS Safari 在某些版本中，即使加了 novalidate，type="number" 仍会强制弹出数字键盘且拦截非数字输入——这不是验证问题，而是输入法控制逻辑，无法用 JS 关闭。
更隐蔽的问题：Android Chrome 对 pattern 属性仍会执行正则匹配（哪怕有 novalidate），只是不显示 UI 提示；所以如果你的自定义规则和 pattern 冲突，可能造成 checkValidity() 返回 false 却无提示，用户摸不着头脑。
- 生产环境建议移除所有
pattern、min、max等原生约束属性，只留语义化type（如type="email"为唤起键盘） - 移动端测试重点看软键盘类型是否符合预期，而不是验证逻辑本身
- 不要依赖
validity对象的全部字段，尤其validity.badInput在不同浏览器中行为不一致
required 属性。它本身不触发 UI，但会让 validity.valueMissing 一直为 true，导致你自己的 checkValidity() 判断失准——这点在调试时很难一眼发现。 
