仅做基础格式校验，无法验证域名有效性或邮箱可达性；需配合pattern正则、提交前trim()清理及后端三重校验（语法解析、mx查询、验证邮件）。
直接用 <input type="email"> 就能触发浏览器内置的邮箱格式校验，但它的作用有限——只检查有没有 @、是否以 @ 开头或结尾、有没有连续 @@ 等基础结构，不验证域名是否存在，也不确认邮箱能不能收信。
type="email" 是起点，不是终点
它适合快速拦截明显错误（比如 user#gmail.com 或空输入），但像 test@.com、me@localhost、a@b.c 这类格式宽松的值，多数浏览器会放行。不能靠它挡掉无效邮箱，更不能跳过后端校验。
加 pattern 提升前端约束力
想让校验稍严格些，可以配合 pattern 属性写一个简明正则：
<input type="email" pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}" required title="请输入有效的邮箱地址">
注意三点：
- 正则里别加
^和$，浏览器自动锚定首尾，加了反而失效 - 推荐小写字母范围
[a-z]，因为pattern默认区分大小写 -
{2,}保证顶级域至少两个字母，拦掉user@domain.c这类明显非法格式
提交前手动清理和校验更可靠
用户粘贴邮箱时可能带不可见字符（如零宽空格 U+200B），或前后有空格。原生校验不自动 trim，容易绕过 required。建议在提交前统一处理：
const emailInput = document.querySelector('input[type="email"]');
emailInput.value = emailInput.value.trim(); // 清空格
if (!emailInput.checkValidity()) {
emailInput.reportValidity(); // 触发原生提示
event.preventDefault();
}
必须后端二次验证
前端所有校验都可被绕过（删 HTML、用 curl 发请求等）。服务端至少要做三件事：
- 用专业库解析语法（如 Python 的
email-validator、Node.js 的isemail） - 查询 MX 记录，确认域名能收邮件
- 发送验证邮件并等待用户点击链接或输入验证码
否则数据库里很快就会积压大量 admin@fake-domain.xxx 或拼写错误的邮箱。
移动端友好小提示type="email" 会让 iOS 和 Android 键盘自动切换成带 @ 和 .com 快捷键的邮箱键盘，这是纯 type="text" 没有的体验优势，值得保留。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
