type="email"仅校验基础格式，要求含一个@、前后非空、@后至少有一个英文点号和两个字母的域名后缀，不查域名存在性、MX记录或发请求，无法拦截test@.com等明显无效地址。
type="email" 的校验到底校什么
浏览器原生的 type="email 只校验基础格式，不验证域名是否存在，也不查 MX 记录或发请求。它只用一个极简正则判断：是否含一个 @，前后是否有非空字符，且 @ 后至少有一个点（.）——比如 a@b.c 会通过，test@ 或 @example.com 会被拦住。
这意味着：user@localhost、me@123.456.789.0、admin@.com（注意这个其实通不过，因为 @. 后没字符）都可能被放行；但 user@[192.168.1.1] 这种带方括号的 IP 写法反而被大多数浏览器拒绝（不符合 HTML 标准定义）。
为什么输入 test@example 也能提交成功
因为 test@example 满足最低要求：有 @，前面非空，后面是 example（不含点），但部分旧版 Chrome 和 Safari 实际上允许它——这是实现差异，不是 bug。HTML 标准只要求“至少一个 @ 和非空前后缀”，没强制要求域名部分必须含 .。
- Chrome 115+ 已收紧，
test@example会触发ValidityState.typeMismatch - Firefox 一直较严格，多数版本拒绝该格式
- 移动端 WebView（尤其 Android 低版本）可能完全跳过校验
如何补全真正可用的域名校验
前端必须自己加逻辑，不能依赖 type="email"。推荐在 input 的 blur 或 submit 时运行更严格的正则：
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i
这个正则强制要求域名部分含至少一个点，且顶级域至少两个字母。但它仍不防 user@domain..com 或 user@-domain.com 这类非法结构。如需更高精度，可用成熟的库如 validator.js 的 isEmail()，它内置了对 DNS 格式、长度、特殊字符的综合判断。
注意：服务端必须重复校验——前端正则可绕过，且不同浏览器对 type="email" 的解析不一致。
form 表单提交时 type="email" 的行为差异
当用户点击 <button type="submit">，浏览器会触发 checkValidity()，若失败则阻止提交并显示默认提示（如“请输入有效的电子邮件地址”）。但这个提示文案不可控，且无法自定义样式。
- 调用
input.reportValidity()可手动触发校验和提示 -
input.validity.typeMismatch为true时，说明格式不满足浏览器内置规则 - 即使
validity.valid === true，也不能认为邮箱真实存在——它只是“看起来像”
真正难的部分不在正则写多长，而在于接受一个事实：浏览器永远只做“格式快筛”，所有业务级校验（比如防止 @gmail.com 冒充企业邮箱、过滤一次性域名）都得靠后端配合或额外前端策略。
