仅用 type="email" 不够，因它仅提供语义提示和基础过滤，不处理空格、零宽字符、域名存在性等，需“原生属性+js补救+后端兜底”三者结合。
浏览器原生 input[type="email"] 能拦截明显错误（比如没 @、空值），但不能替代完整校验；真正可用的方案是「原生属性打底 + JS 补救 + 后端兜底」，三者缺一不可。
为什么只用 type="email" 不够用
它只是个语义提示加基础过滤：Chrome 允许 a@b.c，Safari 可能放过 user@domain（缺顶级域），IE9 及以下直接退化成 text。更关键的是——它不 trim 空格、不处理粘贴进来的零宽字符（U+200B）、不校验域名是否存在，也不管大小写归一化。
常见错误现象： test@example.com 提交成功（前后空格未清理）；user@.com 在某些浏览器里也能过；用户复制带格式文本后点提交，校验直接跳过。
- 必须搭配
required才触发必填检查，否则空值也能提交 -
autocomplete="email"和inputmode="email"是移动端弹出 @ 键的必要条件，尤其在 Safari 中 -
pattern属性不是用来替代type="email"的，而是叠加一层规则；iOS Safari 会忽略它，所以不能单独依赖
如何用 checkValidity() 和 reportValidity() 做轻量 JS 补救
比起手写正则，直接调用原生 API 更稳、更兼容，且能复用浏览器已有的错误文案逻辑。重点在于补上原生漏掉的环节：trim、粘贴清理、主动触发反馈。
- 提交前手动清理：
emailInput.value = emailInput.value.trim() - 监听
input或blur，避免用户粘贴后直接点提交跳过校验 - 调用
emailInput.checkValidity()判断状态，失败时立即emailInput.reportValidity()弹出气泡 - 若需自定义提示，用
emailInput.setCustomValidity("请输入有效邮箱")，但记得在输入恢复合法时调用setCustomValidity("")清空
pattern 正则怎么写才不翻车
HTML 的 pattern 属性会自动锚定整个字符串（隐式加 ^ 和 $），所以不用自己写。但要注意字符类中 - 必须放开头或结尾，否则会被解析为范围符，导致语法错误。
推荐写法：pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}"
- 域名部分允许点号和连字符：
[a-zA-Z0-9.-]+，其中-放在末尾避免歧义 - 顶级域至少两个字母：
\.[a-zA-Z]{2,}，排除.c这类无效情况 - 不要加
^和$，浏览器会自动加上，重复会导致匹配失败 -
title属性必须存在，否则 Chrome 不显示提示文字
后端验证为什么必须做、怎么做才合理
前端所有校验都可被绕过：禁用 JS、抓包改请求、curl 直接 POST，甚至用 Postman 构造恶意长字符串触发正则回溯爆炸。服务端才是最后一道防线。
- 只做两件事：基础语法校验（同前端宽松正则）、发确认邮件；别在注册接口同步查 MX 记录——延迟高、易被限频、MX 存在 ≠ 邮箱真实可用
- 入库前必须标准化：
email.toLowerCase().trim()，否则User@Domain.COM和user@domain.com会被当成两个账号 - 正则别照搬 RFC 5322 全集，V8/Node.js 对复杂正则回溯敏感，简单宽松正则 + 发信确认才是生产环境平衡点
真正上线后暴露的问题，往往不在正则本身，而在空格没 trim、大小写没归一、粘贴字符没清理、后端没发确认邮件却直接算注册成功——这些链路断点，比正则少一个 + 更致命。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
