HTML5表单原生校验是从无到有的根本性升级，通过required、type、pattern等属性实现自动UI提示与提交阻止；checkValidity()静默校验，reportValidity()触发提示；setCustomValidity()覆盖而非补充校验，需手动重置；ValidityState各字段浏览器兼容性差异大，须结合正则兜底。
HTML5 表单原生校验比传统 HTML 严格得多
传统 HTML（即 HTML4/XHTML）本身没有表单验证能力，所谓“验证”全靠 JavaScript 手写或第三方库。HTML5 引入了 required、type="email"、pattern、min/max 等属性，浏览器会自动触发 UI 提示（如红色边框、气泡提示）并阻止表单提交——这是本质区别，不是“增强”，而是从无到有。
checkValidity() 和 reportValidity() 是关键控制点
这两个方法决定了你能否绕过/干预原生校验行为：
-
checkValidity()只返回布尔值，不触发界面反馈，适合静默校验逻辑 -
reportValidity()不仅校验，还会触发浏览器默认错误提示（含焦点滚动、气泡），常用于手动触发校验（比如点击“下一步”时） - 调用
form.reportValidity()会逐个检查所有带校验属性的字段，任一失败就返回false并显示提示 - 若用
event.preventDefault()阻止了submit事件，必须显式调用reportValidity()，否则用户看不到任何反馈
setCustomValidity() 能覆盖原生错误但容易误用
它不是“添加自定义错误”，而是“替换当前字段的验证状态”。空字符串表示通过，非空字符串表示失败并显示该文本：
- 一旦调用了
input.setCustomValidity('邮箱已被注册')，原生type="email"校验就失效了——即使输入的是非法邮箱，也不会再报“请填写有效邮箱” - 必须在每次输入后重置：比如监听
input事件，在校验通过时调用input.setCustomValidity('') - 不建议混用
pattern和setCustomValidity()，逻辑易混乱；优先用pattern做正则约束，只在需要服务端联动（如用户名唯一性）时用setCustomValidity()
不同浏览器对 validity 对象的支持细节不一致
input.validity 是一个 ValidityState 对象，但各字段兼容性有坑：
立即学习“前端免费学习笔记（深入）”；
-
validity.badInput：Chrome 支持，Safari 16.4+ 才支持，Firefox 始终为false（即使输入了非数字到type="number"） -
validity.customError在调用setCustomValidity(str)后才为true，但某些旧版 Edge 不触发invalid事件 -
validity.typeMismatch对type="email"或type="url"有效，但对type="date"在 Safari 中可能不触发（它允许空值或非法格式而不报错） - 真正在意兼容性时，别只依赖
validity.xxx字段，应结合checkValidity()+ 自定义正则兜底
原生校验看似省事，但 validity 对象字段行为不统一、setCustomValidity() 的覆盖逻辑容易误伤、以及 Safari 对日期/数字类型校验的宽松处理，都是上线前必须实测的点。
