能用但仅作基础格式拦截，不验证域名存在性或顶级域完整性；需配合 pattern、title 及 JS 清理（trim、去不可见字符、转小写），后端必须独立校验并保持清理逻辑一致。
input type="email" 能不能直接用
能，但只做最基础的格式拦截，比如拦掉 user@、@example.com、user@@example.com 这类明显错误。它不检查域名是否存在，也不拒绝 hello@world（缺顶级域）这种在旧版 Chrome 中可能通过的值。移动端会自动调出带 @ 的键盘，这是它唯一不可替代的优势。
常见误判点：user@example.中国 这类 IDN 域名必须先转成 Punycode（如 xn--fsq097e.cn），否则原生校验直接失败；用户粘贴时带零宽空格（U+200B）也会让 checkValidity() 返回 false，但肉眼看不见。
pattern 属性怎么写才不误杀合法邮箱
别抄网上“一行通杀”的正则。浏览器对 pattern 是全字符串匹配（隐含 ^$），且它和 type="email" 是叠加生效，不是覆盖。推荐这个组合：
-
type="email"保底防低级错误 -
pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9]+(?:[\.-][a-zA-Z0-9]+)*\.[a-zA-Z]{2,}"允许子域名含点或连字符（如admin@sub-domain.example.com） -
title写具体提示，比如"请输入标准邮箱，如 name@domain.com"，避免只写“格式错误”
注意：[\.-] 中的 - 必须放末尾，否则会被解析为字符范围；[a-zA-Z]{2,} 比 [a-z]{2,} 更稳妥，兼容大小写混用的 TLD（如某些内部系统）。
立即学习“前端免费学习笔记（深入）”；
JavaScript 校验时容易漏掉的三个细节
前端 JS 验证不是补刀，而是兜底。以下三点不处理，用户一粘贴就报错：
- 没
.trim()：用户空格开头/结尾，required可能绕过，checkValidity()却返回false - 没清理不可见字符：除零宽空格外，还有
\u200B、\uFEFF、\u00A0（不间断空格），建议用.replace(/[\u200B-\u200D\uFEFF\u00A0]/g, '') - 大小写没统一：RFC 允许邮箱本地部分（@前）区分大小写，但实际服务端基本都转小写处理，JS 里用
String(email).toLowerCase()再比对更贴近后端行为
为什么后端校验不能省，哪怕前端写了三重验证
因为所有前端验证都能被绕过：form.submit() 直接调用跳过校验、禁用 JS、手动构造 POST 请求、抓包改参数……后端必须独立走一遍完整逻辑：
- 用语言原生函数（如 PHP 的
filter_var($email, FILTER_VALIDATE_EMAIL)）做语法初筛 - 对域名部分查 MX 记录（可选，注册场景建议加）
- 对用户输入做
trim()和不可见字符清理，和前端保持一致 - 禁止临时邮箱（如
@10minutemail.com）需靠域名白/黑名单，不能靠前端 pattern
最常被忽略的是：前后端邮箱清理逻辑不一致——前端 trim 了，后端没 trim，结果数据库存了带空格的邮箱，后续发信或登录全失败。
