type="email"仅做基础格式校验，不验证域名存在性或用户名合法性，IE9及以下不支持，移动端仅优化键盘；pattern与之叠加而非替代；JS正则宜用平衡版，后端校验不可省。
type="email" 能信多少？
它只做最基础的格式拦截：必须含 @、后面得有英文点号和至少两个字母的域名后缀（比如 .com），但不检查用户名里有没有连续点号、开头结尾是不是点或减号、域名是否存在——这些全放行。
- IE9 及以下版本完全不识别
type="email"，会退化成普通text输入框，毫无校验 - 移动端会自动弹出带
@的键盘，这是唯一确定的体验提升点 -
pattern属性可以叠加使用，但它不会替代原生校验，而是额外加一层；比如pattern="(?!.*@163\.com$).*"能禁止 163 邮箱，但用户仍可能绕过 JS 提交
JavaScript 正则验证怎么写才不翻车？
别抄网上那些“完美匹配 RFC 5322”的长正则——它们既难维护，又容易误杀合法邮箱（比如 user+tag@example.org）。用这个平衡版更稳妥：/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/
-
checkValidity()是浏览器原生方法，调用它比自己写正则快，且能复用required、pattern等所有 HTML5 校验逻辑 - 用
onchange或oninput做实时提示可以，但别只依赖它——用户可能直接右键粘贴并点击提交 - 避免在
submit事件里只做一次正则判断就放行；应先调用event.preventDefault()，再综合input.checkValidity()和自定义规则统一决策
pattern 属性和 type="email" 一起用时的陷阱
pattern 不会覆盖 type="email" 的内置规则，而是“先过邮箱格式，再过正则”。但很多开发者误以为写了 pattern 就等于接管了全部校验逻辑。
- 如果把
type改成text再加pattern，就彻底失去原生邮箱语义和移动端键盘优化 -
title属性是pattern失败时的提示文案，不是 placeholder；不写title会导致浏览器用默认英文提示，中文项目务必补上 - 正则中不要漏掉
^和$，否则abc@def@g.com这种明显错误也可能被部分匹配通过
为什么后端校验不能省？
前端所有验证都可被禁用、绕过或伪造。一个 curl 命令就能把 test@ 这种明显非法字符串直接 POST 到接口。
立即学习“前端免费学习笔记（深入）”；
- 后端必须重新解析邮箱结构，推荐用语言标准库（如 Python 的
email-validator、Node.js 的validator.js）而非手写正则 - 真实业务中还要查是否为临时邮箱（如
@guerrillamail.com）、是否已注册、MX 记录是否存在——这些前端根本做不到 - 哪怕前端做了十层校验，后端收到字段后第一行代码仍应是：拒绝空值、拒绝格式不合规、拒绝黑名单域名
if (!isValidEmail(req.body.email)) 里。 
