checkvalidity()仅返回布尔值，不提供具体错误信息；需手动遍历表单控件，通过validity.valid和validationmessage获取各字段验证状态与提示文本。
form 元素的 checkValidity() 只返回布尔值，不告诉你哪错了
浏览器原生表单验证默认只阻止提交并高亮第一个无效字段，checkValidity() 返回 false 但不提供具体错误列表。想拿到全部字段的错误信息，得手动遍历每个 input、select、textarea。
实操建议：
- 用
form.elements或form.querySelectorAll('input, select, textarea')获取所有可验证控件 - 对每个元素调用
element.validity.valid判断是否通过，再查element.validationMessage获取提示文本 - 注意跳过
type="hidden"、disabled或name为空的元素，它们不参与验证 -
validity对象里还有更细的字段（如valueMissing、tooShort），可用于区分错误类型
用 reportValidity() 触发原生提示，但无法捕获错误详情
reportValidity() 会触发浏览器默认的气泡提示，并返回 false（有错误时）或 true（全通过），但它不暴露错误位置和原因——这跟 checkValidity() 一样，只是多了 UI 反馈。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 调用
form.reportValidity()后只看到一个红框+提示，但控制台没输出任何错误字段名 - 误以为它能返回错误数组，结果解构失败
使用场景：适合快速阻断提交并给用户视觉反馈，但不能替代手动收集逻辑。
手动收集错误时，validity 对象的兼容性要注意
validity 是标准 API，现代浏览器都支持，但某些属性在旧版 Safari 或 IE 中行为不一致。比如 badInput 在 Safari 中对非数字输入不触发，patternMismatch 在未设 pattern 属性时可能为 true（尤其配合 inputmode 时）。
实操建议：
- 优先检查
validity.valid === false，再逐个判断具体原因字段 - 避免依赖
validity.customError除非你主动调用了setCustomValidity() - 对日期/时间输入，Chrome 和 Firefox 对空值的
valueMissing判定一致，但 Safari 有时忽略required - 示例：获取第一个错误字段名：
Array.from(form.elements).find(el => !el.validity.valid)?.name
提交前批量收集错误，别等 submit 事件才开始
把错误收集逻辑放在 submit 事件处理器里没问题，但若想在用户离开某字段时就校验（比如实时反馈），就得监听 blur 或 input，这时要注意避免重复计算或干扰原生验证节奏。
性能与体验要点：
- 不要在
input事件中频繁调用checkValidity()，尤其含正则pattern的字段，可能卡顿 - 对
type="email"这类字段，浏览器内部验证开销低，但自定义pattern长度超 100 字符时明显变慢 - 收集结果建议缓存到对象里：
{ email: '请输入有效邮箱', password: '至少8位' }，而不是每次重建数组 - 如果用了
setCustomValidity('')清除自定义错误，记得同步更新你的缓存对象
真正麻烦的是混合了自定义校验（比如用户名是否存在）和原生校验的场景——这时候原生 validity 无法反映异步结果，必须自己维护状态。
