type="email" 仅做极简格式校验，无法替代后端验证；其规则宽松（如me@localhost可通过），不检查DNS、SMTP或IDN域名，且易受零宽字符干扰；pattern正则需谨慎编写，JS校验应结合blur事件与submit前检查，后端必须用专业库解析、查MX记录并发送验证邮件。
type="email" 本身只校验基础格式，别当真
浏览器对 type="email" 的校验非常宽松：它只要求含一个 @、后面至少有一个点（.），且不以 @ 开头或结尾。像 me@localhost、admin@mail.、甚至 test@.com（部分旧版 Chrome）都能通过，但这些显然不是有效邮箱。
它不查 DNS、不连 SMTP、不验证域名是否存在，也不处理 IDN 域名（如含中文的 张三@例子.中国），后者必须先转成 punycode 才能被识别。
- 用户粘贴时可能带零宽字符（U+200B），
checkValidity()会返回false，但输入框里看不见 —— 需手动.trim().replace(/[\u200B-\u200D\uFEFF]/g, '') -
required不会自动 trim，填" user@example.com "可能绕过校验 - 加了
novalidate属性或用 JS 直接调form.submit()，原生校验完全失效
pattern 属性怎么写才不翻车
想收紧前端校验，用 pattern 是最直接的方式，但写法很关键：
- 推荐正则：
[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$—— 小写字母开头，兼容主流邮箱结构，排除user@domain.c这类无效后缀 - 千万别加
^和$：浏览器自动锚定首尾，重复会导致匹配失败 - 不要抄“RFC 5322 全兼容”长正则：iOS Safari 和部分 Android 浏览器直接忽略
pattern，且容易误杀合法邮箱（比如user+tag@gmail.com） -
pattern是可选校验，用户删掉 HTML 或发 POST 请求就能绕过，它不能替代required
JavaScript 校验该在什么时候触发
别一输就校验，也别只信 checkValidity() —— 它只反映当前 HTML 约束状态，不包含你自定义的业务逻辑。
立即学习“前端免费学习笔记（深入）”；
- 提交前校验优先调
input.checkValidity()，再补你的正则：前者已处理空值、required、type="email"规则，避免重复劳动 - 实时反馈用
blur事件比input更合理：避免刚敲a@就报错，也减少卡顿 - 后端返回错误（如“邮箱已被注册”）后，需手动重置校验状态：
input.setCustomValidity("提示文字"); input.reportValidity();，否则下次checkValidity()仍返回true - 如果表单用了
novalidate，JS 校验就是唯一防线，务必覆盖空值、格式、长度（建议总长 ≤ 256 字符）
后端验证漏掉这三步等于没做
前端所有校验只是体验层，攻击者删 DOM 或发 curl 请求就能跳过。后端收到 email 字段后，至少要：
- 用成熟库解析：Python 用
email-validator，Node.js 用isemail—— 比手写正则准得多，支持+tag别名、IDN 域名等 - 查 MX 记录：用
dig MX example.com或 DNS 查询 API，排除@fake-domain.123这类假域名 - 发验证邮件并要求交互：这是唯一确认邮箱真实可用的方式；仅靠格式 + DNS 检查，仍可能漏掉已注销、拒收、防火墙拦截等情况
最常被忽略的是：开发者以为加了 type="email" 就算校验完成，结果数据库里堆满 test@126.com（拼写错误）、admin@localhost（本地测试残留）这类无效邮箱 —— 因为没配后端二次过滤，也没走激活流程。
