type="email"仅做基础格式校验，无法验证邮箱真实性；它用正则粗略检查@和.的存在与顺序，能拦截test@.com等明显错误，但abc@def.gh、me+spam@gmail.com等合法格式也会通过。
input type="email" 的校验到底有多准？
它只做最基础的格式检查，不是邮箱真实性的验证手段。浏览器会用正则粗略匹配 @ 和 . 的存在与顺序，但像 test@.com、user@@domain.com 这类明显错误能拦住，而 abc@def.gh（不存在的顶级域）、me+spam@gmail.com（合法但带标签）全都会通过。
哪些常见邮箱会被 type="email" 拒绝？
实际开发中容易误判的几类：
-
name.surname@company.co.uk—— 多级域名没问题，现代浏览器基本支持 -
user.name+tag@example.org——+后缀是 SMTP 合法扩展，但部分老版本 Safari 会报错 -
"quoted"@example.com—— 带引号的本地部分符合 RFC 5322，但所有主流浏览器都不支持，直接标红 -
admin@mail.—— 末尾带点，被所有浏览器拒绝，但错误提示常是“请填写有效电子邮件地址”，没说明原因
想真正验证邮箱，光靠 type="email" 远远不够
前端只能做轻量过滤，关键校验必须后端做。如果非要加一层 JS 辅助（比如实时提示），推荐用更宽松的正则，而不是复刻浏览器行为：
/^[^\s@]+@[^\s@]+\.[^\s@]+$/
这个表达式比浏览器内置的略宽（比如允许单字母二级域），但避开了过度严格的陷阱。注意：HTMLFormElement.checkValidity() 调用时仍走浏览器原生逻辑，JS 正则只是补充提示，不能替代 submit 时的后端验证。
移动端键盘和用户体验的隐性影响
设置 type="email" 最实在的好处不是校验，是触发手机键盘的 @ 和 . 字符快捷入口。但要注意两点：
- iOS Safari 在
inputmode="email"未普及前，对type="email"的键盘优化更稳定；Android 各厂商差异大，部分国产浏览器会忽略该类型，降级为text - 如果同时设了
pattern（比如pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"），某些 Android 机型会在输入时反复弹出“请输入有效邮箱”的气泡，干扰用户，建议慎用
真实项目里，邮箱字段的健壮性往往卡在「用户输错但没报错」，而不是「浏览器拦得太严」——这点比正则细节更值得花时间设计交互反馈。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
