在 标签上添加 novalidate 属性可声明式禁用 HTML5 原生验证，优先级最高；禁用后需用 checkValidity() 主动校验并结合 JS 实现自定义提示与样式控制。
怎么禁用 HTML5 表单原生验证
直接在 标签上加 novalidate 属性，就能彻底关闭浏览器默认的提交校验行为。这不是 JavaScript 控制，而是声明式禁用，优先级最高。
常见错误是只给 加 required 却没关表单验证，结果点击提交仍弹出「请填写此字段」提示。只要表单有 novalidate，哪怕所有字段都带 required、type="email"，也不会触发原生弹窗或高亮。
-
novalidate是布尔属性，写上即生效，无需赋值（novalidate="false"无效） - 它只影响该
内部，不影响其他表单 - 禁用后，
checkValidity()和reportValidity()仍可调用，但不会自动弹窗
如何手动触发校验并接管提示逻辑
禁用原生验证后，得靠 JS 主动调用 checkValidity() 或 reportValidity() 来获取校验状态，再决定是否提交或展示自定义提示。
checkValidity() 只返回 true/false，不显示任何 UI；reportValidity() 会触发原生提示（除非表单有 novalidate —— 此时它退化为只返回布尔值，不弹窗），所以实际中更推荐用 checkValidity() + 自定义 DOM 操作。
立即学习“前端免费学习笔记（深入）”；
- 对单个字段：调用
inputElement.checkValidity()，配合inputElement.validationMessage获取错误文案 - 对整个表单：遍历
form.elements，逐个调用checkValidity()，汇总结果 - 注意：某些浏览器（如 Safari）对
validationMessage的支持不稳定，建议 fallback 到自己维护的规则映射
为什么不能只靠 removeAttribute('required') 来“动态禁用”
移除 required 属性确实会让 checkValidity() 返回 true，但它不解决根本问题：字段的语义约束已写死在 HTML 中，且用户仍可能通过粘贴、脚本等方式输入非法值，而你失去统一入口去拦截和反馈。
更关键的是，removeAttribute('required') 不影响 type="email" 或 pattern 的校验逻辑 —— 这些依然生效。真正可控的方式是统一收口到 JS 校验函数中，把 HTML 层当作纯结构描述，而非校验逻辑载体。
- HTML5 属性（
required、min、max、pattern）本质是声明式约束，无法条件化启用/禁用 - JS 校验可结合业务状态（如「是否开启邮箱验证」开关）动态调整规则，HTML 属性做不到
- 混合使用（部分字段用原生、部分用 JS）易导致体验割裂：有的报错弹窗，有的静默失败
改写校验触发时机的关键点
原生验证只在表单提交或 input 失焦时触发，而真实场景常需更细粒度控制：比如实时验证邮箱格式、离开手机号字段时才校验长度、提交前统一过一遍。
核心是解耦「事件监听」和「校验执行」：用 addEventListener 绑定 input、blur、submit 等事件，但在回调里不直接调用 reportValidity()，而是走自己的校验函数，再更新 UI 状态（如添加 error class、插入提示 ）。
- 避免在
input事件里频繁调用checkValidity()，尤其含正则的pattern，可能造成输入卡顿 - 对异步校验（如用户名是否已存在），必须等请求完成后再决定是否标记为错误，此时原生验证完全无用
- 移动端要注意
blur触发时机不可靠，建议搭配focusout或显式按钮点击来触发最终校验
最易被忽略的是：禁用原生验证后，很多人忘了重置 :valid/:invalid CSS 伪类的样式依赖 —— 这些样式会失效，必须改用 JS 动态添加 class 来驱动视觉反馈。
