原生表单校验应优先使用checkValidity()和reportValidity()，配合setCustomValidity()注入自定义错误；需及时清空旧错误、合理选择校验时机（blur后启用input实时校验），并用服务端错误字段名匹配DOM元素同步验证状态。
用 checkValidity() 和 reportValidity() 做原生表单校验
浏览器自带的表单验证机制比手写正则更可靠，也更易与无障碍、国际化配合。关键不是禁用它，而是理解它怎么触发、怎么干预。
常见误区是监听 submit 事件后手动调用 preventDefault() 再自己判断——这会绕过原生提示，丢失 :valid/:invalid 伪类和屏幕阅读器支持。
-
checkValidity()只检查，不弹提示；返回true或false -
reportValidity()检查 + 显示默认气泡提示（含本地化文案），返回布尔值 - 在
submit事件中调用reportValidity()，若返回false，就别发请求
form.addEventListener('submit', (e) => {
if (!e.target.reportValidity()) {
e.preventDefault(); // 仅当校验失败时阻止提交
} else {
// 此处可发起 fetch，或跳转
}
});
自定义校验规则必须用 setCustomValidity()
原生 required、type="email" 不够用时（比如“两次输入密码需一致”），不能只靠 JS 判断布尔值，必须把结果注入到表单控件的验证链路里，否则 checkValidity() 仍会返回 true。
核心逻辑：先清空旧错误（setCustomValidity('')），再根据条件设新错误（setCustomValidity('密码不一致')）。空字符串表示“通过”，非空字符串表示“失败”且作为提示文案。
立即学习“Java免费学习笔记（深入）”；
- 必须在每次输入后调用，否则状态滞后
- 错误文案会出现在
reportValidity()的气泡中，自动本地化（取决于浏览器语言） - 不要在
setCustomValidity()中传入 HTML 字符串，它会被当作纯文本渲染
const pwd1 = document.getElementById('password');
const pwd2 = document.getElementById('confirm-password');
[pwd1, pwd2].forEach(el => el.addEventListener('input', () => {
if (pwd1.value && pwd2.value && pwd1.value !== pwd2.value) {
pwd2.setCustomValidity('两次输入的密码不一致');
} else {
pwd2.setCustomValidity(''); // 清除错误才可能变回 valid
}
}));
避免重复触发导致 UI 错乱：校验时机选 input 还是 blur？
实时校验（input）体验流畅但容易干扰用户——比如邮箱还没输完就报错“邮箱格式错误”。延迟校验（blur）更克制，但用户可能没离开字段就点了提交。
折中方案：首次失焦（blur）后启用实时校验，兼顾准确性和响应性。
- 给每个字段加
data-validated="false"标记 -
blur时设为true并立即校验一次 - 之后所有
input都校验，但只更新 UI（不弹气泡） - 提交时仍走
reportValidity()统一兜底
input.addEventListener('blur', () => {
input.dataset.validated = 'true';
input.reportValidity();
});
input.addEventListener('input', () => {
if (input.dataset.validated === 'true') {
// 只更新样式或图标，不调用 reportValidity()
input.classList.toggle('error', !input.checkValidity());
}
});
服务端校验结果如何同步回前端？用 setCustomValidity() 接收 API 错误
前端校验拦不住绕过 JS 的请求，服务端返回的字段级错误（如“手机号已被注册”）必须能反向注入到对应 的验证状态中，否则用户无法直观定位问题。
关键点：服务端返回的错误字段名要和 DOM 的 name 或 id 对齐，然后用 setCustomValidity() 注入，再调用 reportValidity() 触发视觉反馈。
- 不要覆盖用户已输入的合法值，只改验证状态
- 服务端错误优先级高于前端规则，所以应清空已有自定义错误后再设新错误
- 如果多个字段同时出错，逐个调用
setCustomValidity()即可
// 假设 API 返回 { errors: { email: '该邮箱已被注册' } }
const errors = await api.submit(form);
Object.entries(errors).forEach(([field, msg]) => {
const el = document.querySelector(`[name="${field}"]`);
if (el) {
el.setCustomValidity(msg);
el.reportValidity(); // 确保气泡出现
}
});
前端校验不是“做不做”的问题，而是“怎么嵌入标准流程”的问题。最常被忽略的是：不清理 setCustomValidity() 的旧值，导致字段永远标红；或者在 submit 里漏掉 reportValidity() 调用，让自定义错误完全不显示。 
