type="email"仅做前端格式校验，不发邮件、不连服务器；必须配合后端严格校验（语法、长度、MX查询等），前端仅为体验层，后端才是事实层。
HTML type="email" 只校验格式，不发邮件也不连服务器
浏览器内置的 type="email" 仅做基础正则匹配（比如必须含 @、不能有空格），它不会发送任何请求验证邮箱是否真实存在，也不会触发 SMTP 或调用后端。这是最常见的误解——以为加了这个类型就“安全”或“可靠”了。
常见错误现象：test@.com、user@@domain.com 在部分老版本 Chrome 中居然能通过；Safari 对 Unicode 邮箱支持更松，??@example.com 也能提交。
- 使用场景：适合前端快速拦截明显乱输（如
abc、hello world），但绝不能替代后端校验 - 参数差异：
required必须搭配，否则空值也能通过；pattern可覆盖默认规则（但会绕过浏览器原生提示样式） - 兼容性影响：IE10+ 支持，但 Android 4.4 WebView 的
checkValidity()行为不一致，建议始终手动调用reportValidity()
后端才是邮箱验证的真正防线
所有邮箱校验逻辑必须在服务端复现，且要比前端更严格。前端只是体验层，后端才是事实层。
常见错误现象：只用正则 /^.+@.+\..+$/ 就放行；没限制长度（导致 DB 字段溢出）；忽略国际化域名（IDN）解码问题。
立即学习“前端免费学习笔记（深入）”；
- 使用场景：注册、密码重置、通知订阅等任何需要确认用户身份的流程
- 推荐做法：先做语法校验（RFC 5322 子集即可，别硬啃全文），再检查长度（通常 ≤ 254 字符），最后做 DNS MX 记录查询（可选，延迟高，慎用于实时表单）
- 性能影响：MX 查询耗时波动大，不应放在同步注册接口里；可用异步队列+邮件回执方式替代
HTML 邮件输入 + JavaScript 校验的最小可行组合
光靠 type="email" 不够，但全靠 JS 写正则又容易过度设计。一个轻量、可维护、不过度防御的组合是实用选择。
input.addEventListener('blur', () => {
const email = input.value.trim();
// 简单但比浏览器默认更严：禁止开头/结尾空格、连续点、点前后无字符
const isValid = /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
if (!isValid) input.setCustomValidity('邮箱格式不正确');
else input.setCustomValidity('');
});
- 为什么这样做：浏览器默认正则允许
a@b..c，这个正则直接拒绝 - 容易踩的坑：
setCustomValidity('')必须显式调用，否则上次错误会一直卡住提交 - 兼容性注意：
setCustomValidity在 iOS Safari 15.4 前对type="email"支持不稳定，建议统一用type="text"+ 自控校验
真正要防的不是格式，是机器人和误操作
用户输错邮箱，大概率是手滑或复制粘贴带空格；机器人则会批量填 test@test.com 或随机字符串。这两类问题，格式校验都解决不了。
- 关键动作：加
autocomplete="email"提升真用户体验；服务端记录高频失败邮箱并临时限流 - 隐藏陷阱：很多团队把邮箱当唯一 ID 用，但同一邮箱被多人注册（如家庭共用）、或用户换邮箱后无法关联历史数据，这类问题永远不在 HTML 层解决
- 最常被忽略的一点：邮件发送失败日志里，
550 User unknown和554 Transaction failed的含义完全不同，但前端从不感知——校验和送达是两件事
