type="email"仅校验基础格式：必须含一个@，且@前后均有非空字符，@后需有英文点号及至少两个字母的顶级域，但不验证域名存在性、MX记录或邮箱真实性，必须配合后端严格校验。
type="email"到底校验什么
它只做最轻量的语法检查：必须含一个@，@前后都得有至少一个非空白字符，且@后至少有一个点号（.）和点号后的字母（如com、org）。但这些规则浏览器实现不一致——Chrome 可能放过hello@world（无顶级域），Firefox 则更倾向拒绝。
常见错误现象包括：test@.com被部分浏览器接受；user@@example.com会被拦住； admin@mail.example （带空格）可能绕过required但触发格式失败；"john"@example.com（带引号）直接不支持，多数浏览器截断或报错。
-
required只判是否为空字符串，不 trim，也不管空格 - 不验证域名是否存在、MX 记录是否有效、邮箱是否真实可收信
- IDN 域名（如含中文）必须先转为 punycode（
xn--fsq097e.cn），否则无效 - IE9 及以下完全不识别，退化为
type="text"
type="url"的验证边界在哪
type="url"在 Chrome 中接受 example.com 这类无协议地址，Firefox 则要求必须以 http:// 或 https:// 开头。它不校验协议是否真实可用（ftp://、git:// 也能过），也不查 DNS 或连通性。
典型宽松表现：https://a.b.c.d.e.f.g 能过；foo 或 @example.com 会失败；https:// 单独写则格式不完整，被拒绝。
立即学习“前端免费学习笔记（深入）”；
- 移动端键盘适配靠的是
type本身，不是 JS ——type="url"触发带/和.com快捷键的键盘 - 若强制要求 HTTPS，不能只靠
type="url"，得加pattern="^https?://.+" -
pattern是叠加校验，不是替代：先过原生url规则，再跑正则
pattern 和原生 type 混用时的坑
很多人以为写了 pattern 就接管了全部逻辑，其实不然。type="email" pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$" 的效果是：先走浏览器内置邮箱规则（比如拦掉 user@），再用正则二次过滤（比如拦掉 user@163.com）。但 iOS Safari 和旧版 Android 浏览器可能忽略 pattern，且正则里别写 ^ 和 $ —— 浏览器自动添加，重复会导致匹配失效。
-
title属性是pattern失败时的提示文案，不写就显示默认英文，中文项目务必补上 - 想禁用某类邮箱（如
@qq.com），pattern 可行，但用户仍可通过 JS 直接提交绕过 - 用
setCustomValidity()自定义提示时，校验通过后必须调用setCustomValidity('')，否则状态卡死
为什么不能依赖它们做关键判断
所有原生验证只在 form.submit() 或 input.reportValidity() 时触发，JS 主动调用 form.submit() 若没提前校验，就等于跳过全部前端检查。攻击者删 HTML、禁用 JS、或直接发 POST 请求，都能轻松绕过。
- 前端任何验证都只是体验层辅助，后端必须用专业库（如 Python 的
email-validator、Node.js 的isemail）做语法 + MX 查询 + 发送确认邮件 - 最常被忽略的一点：很多团队上线后才发现数据库里堆满
test@123、admin@localhost这类“格式合法但完全不可用”的邮箱 —— 因为只用了type="email"，没设后端二次过滤，也没走激活流程
