JavaScript表单验证必须分层处理：格式层用validity或正则快速筛查，业务层调API校验；始终监听form的submit事件并preventDefault()；错误时聚焦首错字段；setCustomValidity需每次验证后明确设置；服务端校验不可省略且须与前端严格对齐。
JavaScript 表单验证不能只靠 required 或 type="email" 属性——浏览器原生校验太浅，容易被绕过，且错误提示不可控、不统一。
用 addEventListener('submit') 拦截表单提交
直接监听 submit 事件并调用 event.preventDefault()，是可控验证的起点。不这么做，表单会直接提交导致跳转或刷新，验证逻辑根本没机会执行。
常见错误：绑定在按钮的 click 上，但用户按回车仍会触发原生提交；或者忘记 preventDefault()，验证通过了却没阻止默认行为。
- 始终对
<form></form>元素监听submit，不是按钮 - 验证失败时，聚焦第一个出错字段（
input.focus()），提升修复效率 - 避免在验证函数里写
return false代替event.preventDefault()，语义不清且易漏掉
校验逻辑要分层：格式 + 业务规则
邮箱格式正确 ≠ 邮箱真实存在；手机号 11 位 ≠ 是用户本人。前端验证只能做轻量级筛查，必须拆成两层：
立即学习“Java免费学习笔记（深入）”；
-
格式层：用正则或
input.checkValidity()快速过滤明显非法输入（如/^\S+@\S+\.\S+$/判邮箱） - 业务层：比如“用户名是否已存在”“密码两次输入是否一致”，需调用 API 或比对其他字段值
注意：input.validity 对象提供 valid、patternMismatch 等属性，比手写正则判断更可靠，尤其配合 setCustomValidity() 可定制错误信息。
避免手动清空 input.setCustomValidity('') 的坑
很多教程教你在每次输入后调用 setCustomValidity('') 清除旧错误，但这会导致 checkValidity() 始终返回 true，即使后续输入又变非法——因为清空后没再设新错误。
正确做法是：只在验证失败时设错误（input.setCustomValidity('用户名已存在')），验证通过时设空字符串（input.setCustomValidity('')），且必须确保每次验证都走完这个逻辑分支。
- 不要依赖“输入时自动清除”，而应在每次校验执行完毕后明确设置
- 多个字段联动验证（如确认密码）时，两个字段都要调用
setCustomValidity，否则只改一个，另一个的错误状态不会更新 - 使用
reportValidity()主动触发浏览器原生提示，适合简单场景；但样式不可控，慎用于生产环境
服务端才是最终把关者
所有前端验证都可以被禁用或绕过。哪怕你用了最严密的正则、最完善的交互反馈，只要没在服务端重复校验，数据就不可信。
典型疏忽：前端做了邮箱格式检查，服务端却只做非空判断；或前端限制密码长度 8–20 位，服务端没做同样限制，导致数据库字段溢出或安全漏洞。
前后端校验规则必须严格对齐，且服务端校验不能省略任何一项——这是底线，不是可选项。
