type="email"仅校验基础格式：含@、前后有非空字符、@后有英文点号及至少两个字母；pattern与之叠加但兼容性差；blur时JS校验需重置setCustomValidity('')；前后端校验须用统一库对齐。
type="email" 的校验到底检查什么
它只做最轻量的格式拦截：必须含一个 @，且 @ 前后都得有非空白字符，后面还得至少有一个英文点号（.）和点号后的至少两个字母（如 .com）。像 me@localhost、test@domain.c、user@ 都能过；但 @example.com、user@.com、a@@b.co 会被拦。
它不查域名是否存在、不防临时邮箱、不拒绝带 + 号的合法地址（如 user+tag@gmail.com），也不发任何网络请求。移动端会自动弹出带 @ 和 . 的键盘，这是唯一确定的 UX 收益。
为什么加了 pattern 还是校验失效
pattern 和 type="email" 是叠加关系，不是替代。浏览器先跑原生邮箱规则，再跑你写的正则——但很多情况下，pattern 会被忽略或行为不一致：
- Safari 对
pattern+type="email"支持极差，可能直接跳过 - Chrome 要求
pattern写成[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}，不能带^和$，否则报Invalid regular expression - 加了
pattern后，移动端键盘可能退化回普通键盘，失去@快捷键 - 错误提示文案混乱，原生提示（如“请填写有效的电子邮件地址”）可能被覆盖
blur 事件里用 JS 校验怎么写才不卡死状态
别只在 input 或 change 里校验——输入过程中频繁调用正则会导致卡顿，且用户还没输完就报错。推荐用 blur（失焦）触发，并务必手动重置校验状态：
emailInput.addEventListener('blur', () => {
const email = emailInput.value.trim();
const isValid = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/.test(email);
if (!isValid) {
emailInput.setCustomValidity('邮箱格式不正确');
} else {
emailInput.setCustomValidity(''); // ← 这行不能省，否则状态锁死
}
});
注意：setCustomValidity('') 必须显式调用，否则即使用户后来改对了，checkValidity() 仍返回 false。
submit 时如何让前后端校验逻辑对齐
前端校验只是缓冲，后端才是底线。常见断层点：
- 前端用
checkValidity()返回true，但后端收到test@——因为用户禁用 JS 或右键改 DOM - 后端验证失败后，只改了提示文字，没调
setCustomValidity("邮箱已被注册")+reportValidity()，导致表单仍显示“通过” - 前端正则用了
i标志（忽略大小写），后端却严格区分大小写，造成体验不一致
生产环境建议：前端用 validator.isEmail()（支持 Unicode、+ 号、引号等），后端用对应语言的标准库（如 Python 的 email-validator），两者配置保持一致。别信“一次正则打天下”，边界 case 太多，靠手写正则兜底容易漏。
