JavaScript邮箱验证用/^1+@2+.3+$/做基础筛查，手机号用/^1[3-9]\d{9}$/校验11位纯数字；需结合trim()、input事件提示及后端确认，避免过度复杂化或忽略转义、方法误用等细节。\s@ ↩\s@ ↩\s@ ↩

JavaScript 中用 RegExp 对象或正则字面量配合 test()、match() 等方法就能完成邮箱和手机号的格式验证。关键不是死记复杂正则，而是理解常用模式、注意边界和实际限制。

邮箱验证：别只靠“看起来像”

一个合法邮箱格式（RFC 5322）极其复杂，前端验证只需做基础筛查：含一个 @、前后有内容、域名部分含点、整体不能有空格或非法字符。

• 推荐正则：/^[^\s@]+@[^\s@]+\.[^\s@]+$/
• ^ 和 $ 强制匹配整个字符串，避免 "abc@def.comxxx" 被误判通过
• [^\s@]+ 表示“非空格且非 @ 的字符”，确保用户名和域名段不为空、不含空格或多个 @
• 注意：该正则不校验域名是否存在、TLD 长度是否合规（如 .a 不合法），这些需后端配合

国内手机号验证：以 1 开头的 11 位数字

中国大陆手机号目前以 13、14、15、17、18、19 开头，共 11 位。正则应聚焦“长度+开头+纯数字”，不过度细化号段（因运营商持续扩容）。

• 稳妥写法：/^1[3-9]\d{9}$/
• 1[3-9] 匹配 13–19 开头（覆盖现有所有号段）
• \d{9} 确保后面恰好 9 位数字，合起来就是 11 位
• 避免用 /^1[3-9][0-9]{9}$/ —— [0-9] 和 \d 功能相同，但 \d 更简洁；且不用写成 1[3-9]\d{9} 以外的变体（如拆开写 13\d{8} 等），维护成本高

实际使用时的关键操作

验证不是写完正则就结束，要结合用户交互和容错处理：

• 用 test() 判断真假，例如：/^1[3-9]\d{9}$/.test("13812345678") 返回 true
• 输入时可监听 input 事件实时提示，但提交时仍需再次校验（防绕过）
• 对邮箱，可额外用 trim() 去首尾空格，避免 " user@example.com " 失败
• 不要仅依赖前端验证——正则能拦住明显错误，但无法替代后端真实发送邮件/短信确认

常见坑和提醒

看似简单，实操中容易忽略细节：

• 忘记转义：在字符串中写正则要用双反斜杠，比如 new RegExp("^1[3-9]\\d{9}$")，否则 \d 会被当普通字符
• 混淆 match() 和 test()：match() 返回数组或 null，test() 才返回布尔值，表单验证优先用 test()
• 过度追求“100% 正确”：比如严格匹配所有邮箱 RFC 规则，会导致 "user+tag@example.co.uk" 这类合法邮箱被拒，得不偿失
• 国际化考虑：若应用面向海外，手机号正则需按国家调整，不能硬套中国规则