type="email"依赖浏览器内置解析规则而非正则，与pattern属性机制独立；它仅做基础语法校验、触发邮箱键盘，不自动trim或校验TLD/DNS；pattern需手动写无斜杠的字符串正则；空格和零宽字符需JS清洗；严格校验应交由JS正则实现。
type="email" 本身不运行正则，它用的是浏览器内置解析规则
HTML 的 type="email 不是靠你写的正则生效的，它背后是浏览器实现的一套邮箱语法解析逻辑（类似 RFC 5322 的简化子集），不是 RegExp 引擎在跑你的 pattern。这意味着：pattern 属性和 type="email" 是两套独立机制，可以共存，但互不替代。
常见误解是“加了 type="email" 就等于用了某个正则”，其实 Chrome、Firefox、Safari 各自对 user@host 结构的宽松程度不同——比如 test@localhost 在某些浏览器里能过，有些不能；a@b.c 大多能过，但 @example.com 或 user@ 一定失败。
-
type="email"会自动拒绝明显非法结构（缺 @、缺域名、连续点号等），但不校验 TLD 长度或字符集细节 - 它不检查 DNS 可达性，也不做 SMTP 预检，纯语法层面
- 移动端键盘会自动切换为带 @ 和 . 的邮箱专用布局，这是唯一 UI 层面的“智能”体现
pattern 属性里的正则必须手动写，且不能带 / / 斜杠
如果你在 <input type="email"> 上同时加 pattern，那浏览器会在提交前额外用你提供的正则再校验一次。注意：pattern 值是字符串，不是 JS RegExp 字面量，所以不能写 /.../，也不能用 g 或 i 标志。
例如这个写法是错的：pattern="/^[a-z]+@.+\..+$/" —— 浏览器会把它当字面字符串去匹配，根本不会执行正则逻辑。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}" - 锚点
^和$在pattern中可省略，因为浏览器默认全匹配 - 点号要写成
\.（反斜杠+点），否则.表示“任意字符”，会误配user@domainxcom - 如果正则里含双引号，整个属性值得用单引号包裹，避免 HTML 解析错误
为什么用户填了空格还能绕过 type="email" 校验
最常被忽略的事实：type="email" 不自动 trim 输入值。用户粘贴或手输时带首尾空格（如 " user@example.com "），浏览器仍认为它是“非空且含 @”的合法格式，checkValidity() 返回 true，但后端很可能直接报错。
- 解决办法只有前端主动清理：
input.value = input.value.trim()，再调用input.checkValidity() - 零宽字符（U+200B、U+FEFF 等）更隐蔽，肉眼不可见，但会让
checkValidity()返回false，需用input.value.replace(/[\u200B-\u200F\uFEFF]/g, '')清洗 - 不要依赖
required拦截空格——它只看是否为空字符串，不看是否为空白符
真正需要正则校验时，JavaScript 才是可控出口
当你发现 type="email" + pattern 还不够严（比如要禁止 +something 在本地部分，或要求 TLD 必须是 .com / .cn），就得用 JS 手动 test。这时正则写法和普通 JS 完全一致：
const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
- JS 正则支持
^和$，也支持标志位（如/i），比pattern灵活得多 - 别用网上搜来的“超长邮箱正则”——多数过度严格，会拒掉
user+tag@example.co.uk这类真实存在的地址 - 验证时机建议放在
submit事件里，而不是blur或input，避免干扰用户输入节奏
复杂点在于：没有一个正则能 100% 覆盖所有 RFC 合法邮箱，但也没必要追求完美。真正关键的是前后端规则对齐——前端松一点，后端严一点，才是合理分工。
