17370845950

够了，该正则可拦住明显错误邮箱（如user@、@domain.com），接受常见合法格式（如test+tag@gmail.com），配合trim()和长度校验更可靠，但后端必须重复验证并发送确认邮件。

JavaScript 中用 /^[^\s@]+@[^\s@]+\.[^\s@]+$/ 做基础邮箱校验就够了

浏览器端验证邮箱，首要目标不是 100% 符合 RFC 5322，而是拦住明显错误（比如 user@、@domain.com、user@domain），同时不误伤常见合法邮箱（如 test+tag@gmail.com、user.name@sub.domain.co.uk）。过度复杂的正则反而导致兼容性差、可读性低、维护困难。

为什么不用「完美」正则（比如 HTML5 的 type="email" 内置规则）

HTML5 的 type="email" 实际校验非常宽松——它只检查是否含一个 @ 和至少一个点，甚至允许 a@b.c 这种明显不现实的格式。而网上流传的「RFC 级别」正则（动辄上千字符）在 JS 中难以调试，且 RegExp 引擎对嵌套量词支持不一，容易在 Safari 或旧版 Edge 中抛 SyntaxError 或行为异常。

• ^[^\s@]+@[^\s@]+\.[^\s@]+$ 覆盖绝大多数真实场景：非空本地部分 + @ + 非空域名部分 + 至少一个点 + 非空顶级域
• 它拒绝 @example.com、user@、user@@domain.com、user@domain.
• 它接受 u1+tag@x.y.z、admin@localhost（后者虽不发信，但开发环境常见）

实际使用时必须配合 trim() 和长度判断

用户粘贴邮箱常带首尾空格，或输入超长字符串（如 500 字符随机串），光靠正则无法拦截。JS 字符串方法比正则更可靠、更易读。

function isValidEmail(str) {
  const trimmed = String(str).trim();
  if (trimmed.length < 6 || trimmed.length > 254) return false;
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(trimmed);
}

• String(str).trim() 防止 " user@example.com " 被判无效
• 长度限制参考 SMTP 协议：本地部分 ≤ 64 字符，域名 ≤ 253 字符，总长 ≤ 254
• 不要用 str?.trim()?.length —— null 或 undefined 传入 String() 会变成 "null" 或 "undefined"，需先做类型判断或依赖调用方保障输入类型

后端必须重复校验，前端正则只是体验层防护

任何前端校验都可被绕过。真实系统中，提交后端的邮箱必须：

• 用服务端语言（如 Python 的 email-validator、Node.js 的 is-email）做语法 + DNS MX 记录检查（可选）
• 发送确认邮件并要求点击链接，这是唯一能证明邮箱真实有效的手段
• 避免在数据库字段设过短长度（如 VARCHAR(50)），应至少支持 VARCHAR(254)

正则只是第一道门，门后还得有锁和摄像头。漏掉 DNS 检查或跳过确认邮件，再准的正则也白搭。