novalidate 仅禁用浏览器原生表单提交校验（如 required、type、pattern），不影响 submit 事件、checkvalidity() 或 setcustomvalidity()；其核心是解除提交时的自动阻断，校验逻辑需完全由 js 手动控制。
novalidate 属性到底禁用了什么
novalidate 只禁用浏览器原生的表单提交校验（比如 required、type="email"、pattern 触发的弹窗和阻断），但不会影响 submit 事件触发，也不会阻止 JavaScript 手动调用 checkValidity() 或设置 setCustomValidity()。很多人误以为加了 novalidate 就等于“关掉所有校验”，结果发现 reportValidity() 还能弹提示——这是因为后者是 JS 主动调用的，跟 novalidate 无关。
常见错误现象：novalidate 加了，但用户点击提交后页面没反应，也没报错——其实是你没监听 submit 事件，或者监听了却忘了 event.preventDefault()，导致页面刷新掩盖了 JS 校验逻辑。
- 必须手动绑定
form.addEventListener('submit', handler)并调用event.preventDefault() -
novalidate对input的blur或input事件无任何影响，这些时机仍可调用setCustomValidity() - 若同时用了
form.reportValidity()，它仍会检查所有字段的validity状态，哪怕novalidate存在
setCustomValidity 为什么总不生效
setCustomValidity() 是否生效，取决于调用时该元素是否处于“可报告状态”：只有当 validity.valid === false 时，自定义错误消息才会被 reportValidity() 或 checkValidity() 返回；如果当前字段是合法的（validity.valid === true），传入非空字符串也无效——浏览器会忽略它，并把 validationMessage 清为空串。
典型陷阱：在 input 输入过程中反复调用 setCustomValidity('用户名已存在')，但用户还没输完，字段本身仍是合法的（比如长度不够、格式未满），此时错误消息不会显示，控制台也无报错，容易以为 API 坏了。
- 正确做法：先判断业务规则是否违规，再结合
validity.valid决定是否设错 —— 比如if (!isUsernameAvailable) input.setCustomValidity('用户名已存在'); else input.setCustomValidity(''); -
setCustomValidity('')是重置的关键，不能省略；留空字符串才表示“无自定义错误”，否则旧错误会持续滞留 - 注意 DOM 更新时机：在
input事件里设错后，要等下一次渲染周期才能在validationMessage读到新值，直接 console.log 可能拿到旧值
配合 novalidate 做渐进式校验的实操要点
去掉原生校验后，校验节奏完全由你控制：可以只在校验点（如提交时）集中校验，也可以在输入中实时反馈。但两者混合时容易冲突——比如用户正在输邮箱，你提前标红并提示“邮箱格式错误”，但其实他还没输完，这时 checkValidity() 返回 false，反而干扰后续逻辑。
推荐策略：提交前做全量校验 + 输入中做轻量提示（不依赖 setCustomValidity），避免污染原生 validity 状态。
- 提交时统一调用
form.checkValidity()，对每个input手动执行业务校验并调用setCustomValidity()，再调用form.reportValidity() - 输入中用 CSS 类（如
.error）和独立提示文案控制 UI，绕过validity状态，防止reportValidity()误报 - 如果必须用
setCustomValidity实现实时反馈，务必在每次输入后重置：先input.setCustomValidity('')，再按规则设错，否则旧错误残留 - 注意移动端软键盘 submit 键行为：即使有
novalidate，点击键盘“完成”仍可能触发表单提交，需确保submit事件处理覆盖该路径
兼容性与隐藏坑：Safari 的 validity.valid 异常
Safari（尤其 iOS 15–16）对 validity.valid 的判定比 Chrome/FF 更严格：例如一个空 input type="number"，Chrome 认为 validity.valid === true（因为值为空，不违反 number 规则），而 Safari 返回 false，导致 setCustomValidity() 被意外触发。这种差异会让“输入中清空再设错”的逻辑在 Safari 上提前报错。
根本原因不是 bug，而是 Safari 把空值视为“类型不匹配”，而其他浏览器视为空值合法。解决方案不是绕开 validity，而是显式检测字段是否“已开始编辑”。
- 给 input 添加
data-touched="false"，首次blur或非空input时设为true，仅对 touched 字段执行setCustomValidity() - 避免依赖
validity.valid做 UI 控制，改用业务状态变量（如isEmailValid）驱动样式和提示 - 测试时务必用真实 iOS 设备或 Simulator，DevTools 的 User Agent 切换无法复现该行为
最易被忽略的是：novalidate 和 setCustomValidity() 都不解决异步校验（如用户名是否存在）。你需要自己管理 loading 状态、防重复提交、以及异步返回后的错误同步——这部分没有浏览器 API 替你兜底。
