type="email"仅按whatwg规范做极简语法解析：必须含且仅一个@、前后非空、禁连续点号，但放行test@localhost等；不trim、不查dns、不运行正则；pattern为独立叠加机制，需写无斜杠字符串正则。
浏览器对 type="email" 的校验逻辑是啥
它不跑你写的正则，也不查 DNS 或发邮件，只按 WHATWG HTML 规范做极简语法解析：必须含且仅含一个 @，@ 前后都得有非空字符（比如 a@b 过，@example.com 或 user@ 不过），不允许连续点号（user@@domain 拦住），但 test@localhost、a@b.c、me+tag@gmail.com 全部放行。
pattern 和 type="email" 是两套独立机制
加了 pattern 不会覆盖原生校验，而是额外叠加一次匹配——但注意：pattern 值是字符串，不是 JS 正则字面量，所以不能带 / 斜杠或标志位。
- 错误写法：
pattern="/^[a-z]+@.+\..+$/"（浏览器当普通字符串比对，永远不匹配） - 正确写法：
pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}" -
^和$可省略，浏览器默认全匹配 - 点号必须写成
\.，否则.表示任意字符，user@domainxcom也会被误认合法
为什么用户填了空格还能绕过校验
type="email" 完全不 trim，也不清理零宽字符（如 U+200B）。粘贴来的 " user@example.com " 或带隐藏符号的值，checkValidity() 仍返回 true，但后端大概率报错。
- 提交前必须手动
trim()：input.value = input.value.trim() - 建议顺手过滤零宽字符：
.replace(/[\u200B-\u200F\uFEFF]/g, '') -
required对首尾空格无效——浏览器认为“非空”，但实际值不可用
哪些场景下原生校验会失效
它只在表单 submit 或显式调用 checkValidity() 时触发，其他路径几乎不生效。
- JS 直接调用
form.submit()跳过所有校验 - 表单加了
novalidate属性，整个原生验证被禁用 - iOS Safari 和部分旧 Android 浏览器忽略
pattern，只认type="email" - 用户删掉 HTML 或用 curl 发 POST，前端校验形同虚设
真正关键的校验永远在服务端：用成熟库解析 + MX 查询 + 邮件激活，缺一不可。前端那层只是防手误，不是防线。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
