JavaScript表单验证需兼顾实时反馈、兜底校验、无障碍与原生语义；优先使用HTML5原生属性，JS仅作增强；校验逻辑与UI更新应解耦；服务端必须重新校验。
JavaScript 表单验证不是“加个 onsubmit 就完事”，关键在于**用户输入时及时反馈 + 提交时兜底校验 + 无障碍可访问 + 不破坏原生表单语义**。纯靠 required、pattern 等 HTML 属性能覆盖 70% 场景，但复杂逻辑（如密码强度、邮箱唯一性、跨字段联动）必须用 JS，且不能绕过原生验证机制。
用好 HTML5 原生验证属性，别重复造轮子
浏览器原生验证（required、type="email"、minlength、pattern）已足够健壮，且自动触发 :valid/:invalid 伪类、支持屏幕阅读器、兼容 form.reportValidity()。JS 的角色是增强，不是替代。
实操建议：
- 优先用
input type="email"而非type="text"+ 正则 —— 浏览器会做基础格式检查，并在移动设备弹出对应键盘 -
pattern值要写完整正则（不加^$），例如密码至少 8 位：pattern=".{8,}"，而非/^.{8,}$/ - 自定义错误文案用
setCustomValidity()，但必须在每次输入后清空（setCustomValidity('')），否则会锁死提交 - 避免直接修改
input.value来“修正”输入（如自动加空格），这会干扰用户编辑体验和原生验证状态
监听 input 和 blur，而不是只等 submit
用户更需要实时反馈，而不是填完所有字段再点提交才看到一堆红字。重点监听 input（防抖后校验）、blur（失焦时强制校验），而 submit 仅作最终拦截。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 对长文本或密码强度等耗时校验，用
setTimeout防抖（300ms），避免每敲一个键都跑逻辑 -
blur事件比change更可靠 —— 它在失去焦点时立即触发，不依赖回车或点击其他区域 - 不要在
input里直接调用reportValidity()，它会立刻弹原生提示框，打断输入流；改用手动更新 UI 状态（如添加errorclass、插入） - 监听整个
form的submit事件时，务必调用event.preventDefault()，否则页面会刷新
校验逻辑与 DOM 更新要解耦，别混在一起
把“判断是否合法”和“怎么展示错误”分开，否则换 UI 框架或加国际化时就得重写全部验证函数。
实操建议：
- 每个字段的校验写成独立函数，返回
{ valid: boolean, message: string }，例如：function validateEmail(value) {
const re = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
return {
valid: re.test(value),
message: value ? '请输入有效的邮箱地址' : '邮箱不能为空'
};
} - 统一用
form.checkValidity()判断整体是否可通过原生校验，再叠加自定义逻辑（如“两次输入密码不一致”） - 错误提示元素用
aria-live="polite"，确保屏幕阅读器能读出变化；错误文案不要只靠颜色区分（需图标或文字明确标识） - 禁用提交按钮时，同时设
aria-disabled="true"，并保留视觉禁用样式（如灰色 + cursor:not-allowed）
最常被忽略的是：服务端永远要重新校验。前端验证只是提升体验，不能替代后端防护。任何通过绕过 JS 或禁用 JS 提交的请求，后端都必须拒绝 —— 这不是“最佳实践”，是底线。
