type="email"仅校验基础格式，即字符串中必须含一个@且前后均有非空字符，不验证域名存在性、不拦截me@localhost等无效地址，也无法阻止test@.com等明显错误通过；必须配合后端解析、MX记录检查及邮件激活才能确保邮箱真实有效。
type="email"到底校验什么
它只检查字符串里有没有一个@，且@前后都得有非空字符，比如a@b能过，@b或a@会被拦。不查域名是否存在、不防me@localhost这种假地址、也不拒绝test@.com——后者在部分浏览器里反而会通过。
常见翻车点：user@domain（缺后缀）被拦，但admin@mail.或x@y.zzzzzzz却能提交成功；iOS Safari 对它的支持比 Chrome 更弱，有时连基础提示都不弹。
- 移动端自动唤起带
@和.的键盘，这是唯一确定的 UX 收益 - IE9 及以下直接退化成
type="text"，无任何校验逻辑 - 校验只在表单提交或调用
checkValidity()时触发，不是实时的
pattern属性能不能补救
可以加，但不能替代，更不能乱加。浏览器对 pattern 的处理是：先跑 type="email" 自带规则，再跑你写的正则。两者叠加，不是替换。
典型错误： —— 用户输 me@gmail.com 直接被拒，连原生的 @ 检查都没机会走。
- 正则里别写
^和$，浏览器会自动加上，重复就报Invalid regular expression - 大小写敏感，
pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"是较稳妥写法（注意全是小写） - iOS Safari 和旧版 Android 浏览器可能完全忽略
pattern，别把它当主力防线 - 想禁某些域名（如
@163.com），用负向断言：pattern="(?!.*@163\.com$).*"，但得测试兼容性
JavaScript怎么配合才不翻车
别在 input 事件里狂跑正则，容易卡顿；也别只靠 onsubmit 里一次判断就放行。优先复用浏览器原生能力，再补短板。
推荐做法是监听 blur 或显式点击提交时，先调 input.checkValidity()，再用正则过滤明显非法结构（比如连续点号、开头结尾是点）：
emailInput.addEventListener('blur', () => {
const email = emailInput.value.trim();
const isValid = /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
if (!isValid) {
emailInput.setCustomValidity('邮箱格式不正确');
} else {
emailInput.setCustomValidity(''); // ← 这行必须有，否则状态卡死
}
});
-
setCustomValidity('')必须手动调用，否则即使用户改对了，checkValidity()仍返回false - 用
blur比input更合理：避免刚输a@就标红，也减少无效计算 - 正则别追求 RFC 5322 全覆盖，
/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/覆盖主流场景已足够 - 遇到后端返回邮箱格式错误，要同步重置前端状态：先设非空字符串，再立刻设空
为什么后端校验一步都不能省
因为所有前端校验都可被绕过：curl -X POST、禁用 JS、删掉 required 属性、甚至直接改 DOM 提交——这些操作下，type="email" 和 pattern 全部失效。
后端收到字段后，至少要做三件事：
- 用语言标准库解析（如 Python 的
email-validator、Node.js 的validator.isEmail()），别手写正则 - 查 MX 记录是否存在（
dig MX example.com或 DNS 查询 API），排除@fake-domain.123这类假域名 - 发验证邮件并要求点击链接或输入验证码，这是唯一确认邮箱可用的方式
最常被忽略的一点：很多团队上线后发现数据库里堆满 test@、aaa@bbb 这类数据，就因为以为加了 type="email" 就算“做了邮箱校验”，没配后端二次过滤，也没设邮箱激活流程。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
