setCustomValidity() 可自定义表单校验提示文字，传非空字符串触发失败态，传空字符串''表示通过；需在input/blur事件中调用并及时清空；配合:valid/:invalid伪类可实现轻量样式反馈，但JS判断应使用checkValidity()而非依赖伪类状态。
用 setCustomValidity() 控制原生校验提示内容
浏览器自带的表单校验（比如 required、type="email"）会自动弹出英文提示，但无法自定义文字。想换中文或加图标？必须用 setCustomValidity() 手动干预。
关键点在于：只要传入非空字符串，元素就进入“校验失败”状态；传入空字符串 ''，才表示通过。
- 调用时机：通常在
input或blur事件里判断逻辑，再调用setCustomValidity() - 别漏掉重置：用户修改后要主动清空，否则即使输入合法，校验仍卡在失败态
- 注意兼容性：
setCustomValidity()在所有现代浏览器都支持，但 IE10+ 才有
const emailInput = document.querySelector('#email');
emailInput.addEventListener('blur', () => {
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(emailInput.value)) {
emailInput.setCustomValidity('请输入有效的邮箱地址');
} else {
emailInput.setCustomValidity(''); // 必须清空！
}
});
用 :valid 和 :invalid CSS 伪类控制样式
原生校验结果会实时反映在元素的 :valid / :invalid 状态上，这是最轻量的视觉反馈方式，不需要 JS。
- 只对设置了校验属性（如
required、pattern）的表单控件生效 -
:invalid在用户未交互时也可能触发（比如页面加载后空的required输入框），可用:user-invalid（Chrome 102+、Safari 15.4+）规避，但兼容性弱，慎用 - 别依赖
:invalid做 JS 判断——它和 JS 的checkValidity()结果不一定同步，尤其在初始渲染阶段
input:invalid {
border-color: #e53e3e;
}
input:valid {
border-color: #38a169;
}
避免 reportValidity() 强制触发导致体验断裂
提交时调用 form.reportValidity() 会强制校验并弹出所有失败项的默认提示框，打断用户流程。多数场景下不该直接用它。
立即学习“前端免费学习笔记（深入）”；
- 真正需要的是静默校验 + 自定义提示：先调
form.checkValidity()得布尔值，再自己决定怎么展示错误 -
reportValidity()适合快速原型或后台管理页，但对用户友好的产品界面，应隐藏原生弹窗 - 如果用了
event.preventDefault()阻止表单默认提交，又没手动调reportValidity()，错误状态不会自动显示——此时需自行遍历form.querySelectorAll(':invalid')并标记
自定义错误提示 DOM 的位置和更新逻辑
把错误信息塞进 <span class="error"></span> 这类旁路容器里，比依赖浏览器弹窗更可控，也方便做动画或 ARIA 支持。
- 每个校验字段配一个唯一
id，对应错误提示<span id="email-error"></span>，再用aria-describedby="email-error"关联 - 清空提示不能只删文本——还要移除
aria-live="polite"容器里的旧内容，否则屏幕阅读器可能重复播报 - 别在每次
input事件都重写 DOM；debounce 到 300ms 后再更新，防抖同时兼顾响应速度
复杂点往往不在校验规则本身，而在错误状态如何与 UI 同步、何时清除、是否可访问——这些细节不处理好，用户会反复看到过期的红色提示。
