type="email"不可信，因其仅按RFC 5322极小子集校验，放行user@domain..com等无效格式，且存在兼容性问题；需JS补强+后端兜底三层验证。
type="email" 只能做最基础的格式检查，拦不住 test@.com、me@localhost 或 a@b.c 这类明显无效地址；它不查 MX 记录、不发请求、不验证域名真实性，也完全防不住用户手动绕过。真要落地，得靠「浏览器校验 + JS 补强 + 后端兜底」三层配合。
为什么 type="email" 不能信？
浏览器只按 RFC 5322 的极小子集校验：必须含 @、后面得有英文点号和至少两个字母（如 .com），但以下全会放行：
-
user@domain..com（连续点号） -
.user@domain.com（用户名开头是点） -
user.@domain.com（用户名结尾是点） -
user@-domain.com（域名开头是减号） -
user@domain.c（顶级域只有 1 个字母）
iOS Safari 会忽略 pattern 属性，旧 Android 浏览器对 setCustomValidity 支持不稳定；IE9 及以下直接退化成 type="text"，零校验。
用 setCustomValidity 补严格式校验
比原生 type="email" 更靠谱的做法是：统一用 type="text"，再用 JS 控制校验逻辑，避免兼容性翻车。
- 正则建议用这个平衡版：
/^[^\s@]+@[^\s@]+\.[^\s@]+$/—— 拦掉首尾空格、连续@、点号孤立等情况 - 必须显式调用
input.setCustomValidity("")清空错误态，否则上次失败会一直卡住后续提交 - 监听
blur或input，别只等submit；用户改完就得立刻反馈 - 移动端键盘体验会损失（没了 @ 键快捷入口），但换来的是可控性和一致性
后端返回验证状态后，怎么安全更新前端 UI？
服务端返回的字段必须明确区分「格式合法」「邮箱已注册」「未激活」「MX 不存在」等状态，前端不能靠字符串模糊匹配来设样式或提示。
- 例如后端返回
{ valid: true, activated: false, exists: true }，前端据此控制「已验证」徽章是否显示、是否禁用提交按钮 - 避免写
if (res.message.includes('已存在'))这类脆弱判断，字段语义不清时容易漏判或误判 - 如果后端只返回
status: "success"，前端就无法区分是「格式通过」还是「激活成功」，UI 状态就会错乱
真正难的不是写正则，而是让前后端对「验证」这件事的定义保持一致——格式校验、存在性检查、激活状态，这三者在代码里必须是三个独立开关，而不是混在一个布尔值里来回猜。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
