推荐使用正则/^[a-zA-Z0-9.\_%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/配合test()方法校验邮箱，需加^$、trim()，并辅以后端完整校验。
用 test() 方法快速验证邮箱字符串
JavaScript 本身没有内置邮箱校验函数，最常用方式是调用正则的 test() 方法。别直接套网上搜到的“超长正则”，多数既不严谨也不实用——RFC 5322 定义的合法邮箱格式过于复杂，前端只需拦截明显错误即可。
推荐一个平衡可读性、覆盖常见场景、且避开已知陷阱的正则：
/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/
-
^和$必须加上，否则"abc@def.comxxx"这类也会通过 -
[a-zA-Z0-9._%+-]+匹配用户名部分：允许字母、数字、点、下划线、百分号、加号、减号（注意-放末尾避免被解析为范围符） -
@后域名部分限制了至少一个点 + 至少两个字母的顶级域，排除了user@domain.c这类无效 TLD
为什么 input[type="email"] 不够用
浏览器原生 input[type="email"] 的校验规则比 JS 正则更宽松：它接受 "a@b" 或 "user@.com"，甚至某些带空格的字符串（取决于浏览器实现）。这意味着用户可能在表单提交前没看到错误，直到后端返回 400。
所以实际项目中应同时使用 HTML 属性 + JS 正则双重校验：
立即学习“Java免费学习笔记（深入）”；
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
<input type="email" id="email" required>
并在 JS 中主动调用：
const emailInput = document.getElementById('email');
const isValid = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/.test(emailInput.value.trim());
- 务必对输入值调用
trim()，否则前后空格会导致合法邮箱被误判失败 - 不要依赖
emailInput.validity.valid，它的行为不可控且不一致
常见误判和边界情况
这个正则会拒绝一些真实但罕见的合法邮箱（如带引号的 "john..doe"@example.com），但这是有意为之——这些格式几乎不会出现在用户注册场景，强行支持反而增加维护成本和潜在漏洞。
真正要警惕的是以下几类“看起来像邮箱”的误判：
-
"user@domain..com"→ 域名含连续点，正则中[a-zA-Z0-9.-]+允许点但不允许多个连续点，能正确拦截 -
"user@domain."→ 结尾是点，\.[a-zA-Z]{2,}要求点后至少两个字母，会被拒绝 -
"user@domain.co.uk"→ 双重 TLD，正则中的[a-zA-Z]{2,}仍匹配uk，没问题 -
"user+tag@gmail.com"→+在用户名中合法，正则已包含+，支持
后端必须重新校验，JS 正则只是第一道过滤
所有前端校验都可被绕过。用户禁用 JS、用 curl 直接 POST、或修改 DOM 后提交，都会让 JS 正则失效。因此后端必须用服务端语言（如 Node.js 的 validator.isEmail()、Python 的 email-validator）做完整校验，并建议发送确认邮件。
前端正则唯一目标是：让用户在点击提交前就感知明显格式错误，减少无效请求和体验挫败感。别让它承担本不属于它的责任。
