不能可靠校验。HTML input 的 pattern 属性不支持 ^ 和 $ 锚点，仅匹配子串，无法保证完整邮箱格式；type="email" 更稳妥但也不符合 RFC 5322；真正校验需 JS 主动调用 test() 并配合边界符正则及服务端确认。

HTML input 的 pattern 属性能直接校验邮箱吗？

不能可靠校验。浏览器原生 pattern 只在提交时触发，且不支持 ^ 和 $ 锚点（会被忽略），实际匹配的是子串而非完整值。比如 pattern=".+@.+\..+" 会把 "abc@def.gh@ij.kl" 也当作合法邮箱——因为它确实包含一个 @ 和一个 .。

更关键的是：HTML5 原生 type="email" 已经做了基础格式检查（如必须含 @、不能以 @ 开头等），比手写简单 pattern 更稳妥，但依然不等于 RFC 5322 标准校验。

用 JavaScript 的 test() 配合正则做真正校验

必须用 JS 主动调用 RegExp.prototype.test()，并确保正则覆盖常见邮箱结构，同时注意边界和转义。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 推荐正则：/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i —— 小写修饰符 i 处理大小写，^ 和 $ 保证首尾匹配
• 别用网上那些过度复杂的“RFC 兼容”正则，它们易出错、难维护，且对前端表单无实际增益
• 校验时机建议放在 input 的 blur 或 submit 事件里，避免每打一个字都报错
• 示例代码片段：

  const emailInput = document.querySelector('input[name="email"]');
  const emailRegex = /^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i;
  
  emailInput.addEventListener('blur', () => {
    if (!emailRegex.test(emailInput.value.trim())) {
      emailInput.setCustomValidity('请输入有效的邮箱地址');
    } else {
      emailInput.setCustomValidity('');
    }
  });

setCustomValidity() 和原生验证怎么共存？

setCustomValidity() 会覆盖浏览器默认的 type="email" 提示，所以得手动补全基础检查逻辑，否则用户输 "abc" 也不会报错。

立即学习“前端免费学习笔记（深入）”；

• 先清空自定义错误：element.setCustomValidity('')，再根据正则结果设新值
• 务必配合 required 属性使用，否则空值不会触发验证
• 如果用了 novalidate 在 form 上，那所有原生校验（包括 required）都会失效，只靠 JS 控制
• 移动端键盘可能因 type="email" 自动弹出 @ 符号键，这个体验优势别为了写正则而丢掉

为什么服务器端校验绝对不能省？

前端正则只是用户体验优化，用户禁用 JS、绕过表单、用 curl 直接发请求，都能跳过所有前端校验。

• 后端必须重新解析并验证邮箱格式，且建议用对应语言的标准库（如 Python 的 email-validator，Node.js 的 validator.js）而非复刻前端正则
• 真正关键的不是“格式对不对”，而是“这个邮箱能不能收信”——最终要靠发送确认邮件 + 验证链接完成闭环
• 正则里写的 [a-z]{2,} 看似合理，但像 .museum、.travel 这类长域名会被误判；真实 TLD 列表在持续更新，正则无法动态同步

正则校验邮箱这件事，前端能做的只是快速拦截明显错误，真正的防线在服务端和邮件确认流程里。最容易被忽略的是：把正则当最终判断，却忘了它连 "test@localhost" 都可能放过——而这种地址根本发不出邮件。