type="email"原生校验仅做宽松格式检查，只要含单个@且前后各有一个字符即通过，无法验证邮箱真实存在或服务端兼容性。
input type="email" 的原生校验到底靠不靠谱
它能拦住明显错误的格式（比如没有 @、没有域名），但无法保证邮箱真实存在或可收信。浏览器只做基础正则匹配，required 属性只是检查是否为空，不是“验证有效性”。别把它当后端校验用，也别指望它识别 user+tag@example.com 这类合法变体是否被服务端支持。
为什么输入 test@ 都能通过校验
因为 HTML5 规范里 type="email" 的校验规则非常宽松：只要含一个 @，且 @ 前后都有至少一个字符就算通过。所以 test@、@example、a@b.c 全部合法。真正拦截的是 test（无 @）或 test@@example.com（双 @）这类明显错误。
- Chrome / Firefox / Safari 都遵循同一套基本规则，差异极小
- 移动端键盘会自动弹出 @ 和 .com 快捷键，但不改变校验逻辑
- 想加强限制？得靠
pattern属性配合自定义正则，例如pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"
如何触发并读取校验失败状态
用户提交表单时，浏览器会自动调用 checkValidity() 并阻止提交；也可手动调用该方法判断当前值是否通过校验。失败时，validity.valid 为 false，而 validity.typeMismatch 为 true（这是最常见失败原因）。
const emailInput = document.querySelector('input[type="email"]');
emailInput.addEventListener('blur', () => {
if (!emailInput.checkValidity()) {
console.log('格式不对，比如缺 @ 或域名不完整');
}
});
- 不要依赖
invalid事件来“捕获错误”，它只在浏览器决定校验失败时触发，时机不可控 -
setCustomValidity('')能清空自定义错误，但若留空字符串，不会覆盖原生校验结果 - 样式控制用
:invalid伪类即可，但注意它在输入框为空且有required时也会生效
和服务端校验怎么配合才不翻车
前端校验只是体验优化，所有邮箱字段必须由后端用更严格规则（比如 DNS MX 记录检查、SMTP 探针）二次确认。常见翻车点是前端用宽松正则，后端却拒绝 admin@mail.co.uk 这种合法长域名，或者接受 "quoted"@example.com 这种 RFC 合法但极少使用的格式。
- 前后端邮箱正则尽量统一，推荐使用经过验证的开源库（如 validator.js 的
isEmail()） - 不要在前端用 JavaScript 正则替代
type="email"，两者目的不同：前者防注入/格式引导，后者提供无障碍和移动端适配 - 如果后端返回邮箱已被注册，前端应显示具体提示，而不是笼统说“邮箱格式错误”
真正麻烦的不是写对 type="email"，而是搞清它能做什么、不能做什么，以及它和你后端那串正则之间差了哪几层抽象。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
