JavaScript表单验证应侧重用户体验而非安全，需结合实时input监听、防抖、原生API（如setCustomValidity）及后端独立校验，避免正则漏洞与前端依赖。
JavaScript 表单验证不能只靠 onsubmit 拦住用户，更不能把校验逻辑全塞进前端——它本质是用户体验层的“友好提示”，而非安全防线。
用 addEventListener('input') 实时反馈，而不是等提交才报错
用户输错邮箱后立刻看到红色提示，比点“提交”后跳个 alert('邮箱格式错误') 的体验好得多。关键是监听时机和节流：
- 对
email、tel、password等字段，优先用input事件（非change），保证每敲一个字符都可响应 - 避免高频触发：对模糊匹配类校验（如用户名是否已存在），用
setTimeout+clearTimeout做简单防抖，延迟 300ms 再发请求 - 别在
input里直接调用后端接口查重——先做前端基础格式校验（如邮箱正则/^[^\s@]+@[^\s@]+\.[^\s@]+$/），再决定是否需要异步检查
用 setCustomValidity() 配合原生表单 API，少写 DOM 操作
现代浏览器支持 HTML5 表单约束（required、minlength、pattern），但默认提示不友好。用原生 API 覆盖提示更轻量：
- 给输入框绑定
input事件，在回调中调用inputElement.setCustomValidity('')清空错误，或inputElement.setCustomValidity('密码至少8位')设置错误 - 触发
checkValidity()或让表单自然提交时，浏览器会自动显示你设的提示，并给元素加:invalidCSS 状态 - 注意：只要
setCustomValidity('xxx')中字符串非空，该字段就始终视为无效——忘记清空会导致后续输入也无法通过校验
后端必须独立校验，前端验证只是“加速器”
所有前端校验逻辑都可以被绕过：禁用 JS、改 DOM、抓包重放……所以：
立即学习“Java免费学习笔记（深入）”；
- 密码强度、邮箱格式、手机号长度等，后端必须用相同规则再验一遍，不能信任
req.body.email已合规 - 敏感操作（如修改密码、删除账户）必须校验 CSRF Token 或 session 绑定，不能只靠“用户已登录”这个前端传来的 flag
- 返回错误时，后端应明确指出哪个字段出问题（如
{ "field": "email", "message": "域名不合法" }），前端据此定位并高亮对应输入框，而不是笼统弹“请求失败”
最常被忽略的一点：正则表达式里别写死中文提示，比如 /^[\u4e00-\u9fa5a-zA-Z0-9_]{2,16}$/.test(value) 看似限制了用户名，但没排除全角空格、零宽字符、BOM 头——这些字符肉眼不可见，却可能让后端存储异常或引发 XSS。真正安全的校验，得在后端用 Unicode-aware 的库（如 Python 的 regex 模块）做归一化和过滤。
