够了，该正则可拦住明显错误邮箱（如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)
