不能只靠 input[type="email"] 判断邮箱是否正确——它仅拦截明显错误，需结合 checkvalidity() 与宽松正则 /^\s+@\s+.\s+$/ 校验，并在 blur 或 submit 时触发，服务端必须重验且发确认邮件。
不能只靠 input[type="email"] 判断邮箱是否“正确”——它只拦住明显错误，比如没 @ 或连点都缺，但 user@.com、test@localhost 这类在部分浏览器里能过，提交后照样出问题。
用 type="email" 是起点，不是终点
它提供三样实际价值：软键盘自动弹出 @ 键、基础格式拦截、配合 required 触发必填提示。但别把它当校验主力。
- 不要单独依赖它做唯一判断，Safari 允许
user@domain（无顶级域），Chrome 对a@b.c不报错 - 避免用
pattern替代type="email"，否则会禁用浏览器原生邮箱逻辑（如自动补全、拼写检查） - 必须加
required，否则空值也能通过checkValidity()
checkValidity() + 宽松正则才是最小可行方案
浏览器原生 checkValidity() 会触发 type="email" 和 required 的校验，但结果仍不够稳。得补一层 JS 正则，重点是“够用、不崩、好维护”。
- 校验时机选
blur或submit，别用input——实时验证太干扰输入 - 推荐正则：
/^[^\s@]+@[^\s@]+\.[^\s@]+$/，排除空格和孤立@，强制要求域名中至少一个点且不在开头/结尾 - 开发环境要支持
dev@host或test@localhost？单独加分支判断，别硬塞进主正则里 - 出错时调用
input.setCustomValidity("请输入有效邮箱")再input.reportValidity()，才能控制提示文案
服务端必须重验，且不能查 MX 记录
前端所有校验都可被绕过：禁 JS、改 HTML、抓包重放。服务端收到的邮箱字段，必须重新走一遍基础语法校验 + 发送确认邮件。
- 服务端正则和前端保持一致即可，别上 RFC 5322 全集——V8/Node.js 遇到恶意长字符串可能回溯爆炸
- 绝对不要在注册接口同步查 MX 记录：延迟高、易被限频、MX 存在 ≠ 邮箱真实可用
- 入库前标准化：转小写、去首尾空格、折叠连续点（如
user..name@gmail.com→user.name@gmail.com），否则同一邮箱存成多个账号
真正上线后翻车的，往往不是正则写错了，而是本地测试用 user@localhost 没适配、用户粘贴带空格的邮箱没 trim、或者后端忘了发激活邮件就直接标记为“已验证”。这些链路细节比正则本身更值得盯紧。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
