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"这类合法邮箱被拒，得不偿失 - 国际化考虑：若应用面向海外，手机号正则需按国家调整，不能硬套中国规则
