表单验证不该全靠正则。正则适合格式校验，不适用业务逻辑判断；应先 trim、再简单判断、最后正则兜底；需注意边界情况、分国家处理手机号、拆解密码强度检查；控制触发时机防卡顿；优先用原生校验API，后端必须二次校验。
表单验证该不该全靠正则？
不能。正则适合校验格式，不适合判断业务逻辑（比如“密码不能和用户名相同”“手机号是否已被注册”）。过度依赖正则会让代码难读、难调、难改，还容易漏掉空格、全角字符、国际化输入等边界情况。
实际做法是：先用 trim() 清空首尾空格，再用简单判断（如 Length、required 属性）筛掉明显无效值，最后用正则做格式兜底。
常用正则写法与典型陷阱
很多开发者直接抄网上“最强邮箱正则”，结果连 test@example.co.uk 都不通过；或者用 /^d+$/ 校验手机号，却忽略了 +86 138 1234 5678 这类合法输入。
-
/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/是较平衡的邮箱正则，但不覆盖所有 RFC 合法邮箱——够用即可 - 手机号建议按国家/地区分治：
/^1[3-9]d{9}$/（中国大陆），别试图一个正则通吃全球 - 密码强度不要用超长正则硬套，拆成多个检查更清晰：
password.length >= 8、/(?=.*[a-z])/.test(password)、/(?=.*d)/.test(password) - 所有正则必须加
^和$，否则"abc123@test" + "x"也能通过/d+@/
如何让正则验证不卡 UI？
用户每敲一个键就跑一遍复杂正则，尤其在 input 事件里，会导致输入延迟、光标跳动。关键不是优化正则本身，而是控制触发时机。
立即学习“Java免费学习笔记（深入）”；
- 用
blur事件做最终校验，input只做轻量提示（如长度不足时标红边框） - 对实时校验加节流：
setTimeout延迟 300ms，且每次新输入都清除上一个定时器 - 避免在循环中反复调用
regexp.prototype.test()—— 提前用字面量创建正则对象，复用实例
const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/; function validateEmail(value) { return value && emailRegex.test(value.trim()); }比正则更可靠的是什么？
浏览器原生 checkValidity() 和 setCustomValidity()。它们自动处理空值、必填、类型转换（如 type="email" 自带基础校验），还能和 css 伪类 :valid/:invalid 联动。
真正需要手写正则的场景其实很少：身份证号、银行卡号、自定义协议格式等。其他时候，优先用 required、minlength、pattern 属性，再辅以 js 补充逻辑。
最常被忽略的一点：后端永远要做二次校验。前端正则只是用户体验优化，不是安全防线。