最可靠的方式是直接调用 input.checkValidity() 进行浏览器原生校验，需确保 input 已渲染、type="email" 且 required，并在 setCustomValidity 后重置状态；pattern 应小写、无 ^$、配合 type 和 required；后端失败后须用 setCustomValidity + reportValidity 恢复错误态。
直接用 checkValidity() 判断最可靠
别自己写正则再跑一遍，先调浏览器原生校验。只要 input 有 type="email" 和 required，input.checkValidity() 就会综合判断：是否为空、是否含 @、是否有点、是否满足基础结构。它比手写正则更稳，因为已内置了浏览器对 RFC 子集的解析逻辑。
常见错误现象：手动用 /^[a-z0-9@.]+$/.test(input.value) 这类简单正则，结果 me@localhost 或 admin@mail. 反而被放过；或者没考虑 required 状态，空值时也返回 true。
- 必须确保 input 已渲染到 DOM，否则
checkValidity()返回undefined - 如果之前调过
setCustomValidity("xxx")，得先设为空字符串重置状态：input.setCustomValidity("") - 不要在
input事件里高频调用——卡顿且无意义，等用户提交或失焦时再查
pattern 属性怎么写才不被 Safari 忽略
iOS Safari 对 pattern 支持极弱，稍写错就整个属性失效。关键不是“多严格”，而是“别触发浏览器弃用逻辑”。
典型错误：加 ^ 和 $（浏览器自动锚定，重复会导致匹配失败）、用大写字母（pattern 默认区分大小写）、正则过长（Safari 直接跳过）。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}"（小写，无 ^$，末尾不加 $） - 必须配合
type="email"和required，否则 pattern 不生效 - 加
title="请输入有效邮箱"，部分安卓浏览器会在报错时显示该提示
后端验证失败后，前端表单怎么“重新变红”
光改 DOM 文本或清空 value 没用。浏览器内部的 validity 状态不会自动更新，下次调 checkValidity() 还是 true。
常见错误现象：后端返回“邮箱已被注册”，前端只弹提示，但表单仍显示绿色边框、提交按钮可点，用户以为没问题。
- 正确做法：先设自定义错误：
input.setCustomValidity("邮箱已被注册") - 再强制触发校验：
input.reportValidity() - 用户修改后，必须手动清除：
input.setCustomValidity("")，否则一直卡在 invalid 状态
为什么 type="email" 总感觉“没拦住”
它本来就不打算拦住所有非法输入。它的设计目标是防手误，不是替代后端。比如 test@.com、user@@domain.com 会被拦，但 me@localhost、x@y.zzzzz 都能过——因为浏览器不查 DNS，也不管域名是否存在。
真正容易被忽略的是：你加了 type="email"，但没加 required，用户提交空值照样通过；或者用了 type="text" 却只靠 JS 校验，移动端键盘不弹出 @ 键，体验直接打折。
- 移动端体验依赖
type="email"，不是pattern - 任何前端校验都可被绕过，后端必须用专业库（如 Python 的
email-validator）+ MX 记录查询 + 发送激活邮件三重验证 - 别信“RFC 5322 全兼容”正则——它在
pattern里基本失效，还拖慢 Safari 渲染
