checkValidity()需显式调用才能触发原生校验和错误气泡；submit事件中用if(!form.checkValidity())return false;最轻量；setCustomValidity()必须及时清空否则永久失效；reportValidity()可强制显示气泡。
表单提交前用 checkValidity() 触发原生校验
浏览器自带的 required、minlength、type="email" 等属性不会自动弹出提示，必须显式调用校验方法。直接监听 submit 事件并调用 form.checkValidity() 是最轻量的方式——它不阻止默认行为，但会触发元素的伪类 :invalid 和错误气泡（如果用户已交互过）。
常见错误是只靠 CSS 样式判断，比如写 input:invalid { border: 1px solid red; }，但用户没输任何内容时，:invalid 不会生效（因为未触发校验）。必须先调用 checkValidity() 或让浏览器自动触发（如聚焦后失焦、点击提交）。
- 在
submit事件处理器中第一行写if (!form.checkValidity()) return false; - 不要用
preventDefault()后再手动显示错误——这会绕过原生气泡，且需额外维护状态 -
checkValidity()返回false时，首个无效字段会自动获得焦点（可被setCustomValidity('')覆盖）
setCustomValidity() 要清空才能恢复原生校验
一旦对某个 <input> 调用了 setCustomValidity('用户名不能为空')，该字段就永久处于“自定义错误”状态，即使后续输入合法，checkValidity() 仍返回 false。这是最容易踩的坑。
- 每次输入变化（
input或blur）都应检查逻辑，并调用input.setCustomValidity('')清空错误 - 仅在真正不满足业务规则时才设非空字符串，例如：
if (value.length - 清空后，原生规则（如
required）才会重新起作用
后端校验失败后，前端要复位 setCustomValidity() 并聚焦
用户填完提交，后端返回「昵称已被占用」，此时不能只改 DOM 显示错误文字——必须同步调用 nicknameInput.setCustomValidity('昵称已被占用')，否则下次点提交，checkValidity() 仍认为它合法（因为上次清空了）。
立即学习“前端免费学习笔记（深入）”；
- 后端返回错误字段名（如
{ field: 'nickname', message: '已被占用' }），前端匹配到对应<input name="nickname"> - 先
input.setCustomValidity(message)，再input.reportValidity()强制显示气泡 - 紧接着
input.focus()，避免用户看不到错误提示 - 注意：不要在响应里重复调用
setCustomValidity('')——那会把后端报的错直接吞掉
移动端 iOS Safari 的 reportValidity() 兼容性问题
iOS 15.4 之前，reportValidity() 在某些机型上不显示气泡，或只在第二次调用才生效。这不是 bug，而是 Safari 对“用户手势”的严格判定：必须由明确的用户操作（如点击按钮）触发，且不能在异步回调（如 fetch().then()）里调用。
- 把
reportValidity()放在按钮的onclick或submit事件最开头（同步执行） - 后端校验失败后，改用
input.classList.add('error')+ 手动插入<span class="error-msg">xxx</span>作为降级方案 - 避免在
setTimeout(() => { input.reportValidity() }, 0)中调用——iOS 会拒绝显示
复杂点在于：原生校验气泡是浏览器控制的，无法统一样式；而手写校验又要处理焦点、清空、重试等状态。多数项目最后都退回到「禁用原生，全手写」，但其实只要守住 setCustomValidity('') 的清空时机和 reportValidity() 的调用上下文，原生方案足够可靠。
