HTML的type="email"仅作基础格式校验，无法验证邮箱真实性，必须配合后端解析、MX记录检查及邮件激活才能确保有效。
HTML 自带的 type="email" 只做基础格式校验，不保证邮箱真实存在，也不能替代后端验证。
为什么 input type="email" 经常“看起来没用”
浏览器只按 RFC 5322 的子集校验，比如 user@domain（缺后缀）或 @example.com（缺用户名）会被拦住，但 test@.com、a@b.c 甚至 x@y.zzzzzzz 都能通过。它不查 DNS、不连 SMTP，也不管域名是否存在。
- 常见错误现象：
input提交时没报错，但后端收不到邮件，或注册失败 - 使用场景：仅适合表单初筛，比如防用户手误输成
name#gmail.com - 性能影响：零开销，纯前端正则匹配，无网络请求
pattern 属性能补多少短板
可以加更严格的正则，比如限制常见顶级域、禁止连续点号等，但要注意：iOS Safari 和部分旧 Android 浏览器会忽略 pattern，且正则太长反而容易漏掉合法邮箱（比如带 + 号的 Gmail 别名 user+tag@gmail.com）。
- 推荐写法：
<input type="email" pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"> - 参数差异：
pattern是可选校验，用户仍可绕过（如直接 JS 提交），required才真正阻止空提交 - 容易踩的坑：别用
^和$—— 浏览器自动添加，重复会导致匹配失败
真要靠谱，必须后端再验
前端任何校验都只是体验优化，攻击者删掉 HTML 或发 POST 请求就能跳过所有限制。后端收到 email 字段后，至少要做三件事：
立即学习“前端免费学习笔记（深入）”；
- 用语言原生库解析（如 Python 的
email-validator，Node.js 的isemail），比手写正则准得多 - 检查 MX 记录是否存在（
dig MX example.com或调用 DNS 查询 API），排除@fake-domain.123这类假域名 - 发验证邮件并要求点击链接或输入验证码，这是唯一确认邮箱可用的方式
最常被忽略的一点：很多开发者以为加了 type="email" 就算“做了邮箱校验”，结果上线后发现大量无效邮箱堆积在数据库里——因为没配后端二次过滤，也没设邮箱激活流程。
