html5 type="email" 默认校验极松，仅检查含@和至少一个点；应配合pattern、inputmode="email"、autocomplete="email"增强体验与约束，并始终服务端独立校验。
HTML5 type="email" 的默认校验到底有多松？
它只检查是否含一个 @ 和至少一个点（.），比如 "a@b.c"、"test@.com" 甚至 "@example." 都能通过。浏览器根本不验证域名是否存在、本地部分是否合法、是否有连续点或开头结尾是点等 RFC 5322 规则。
用 pattern 替代默认校验的实操要点
直接覆盖原生行为，不依赖 JS 就能增强约束。但注意：pattern 只在提交时触发，且正则默认**不带全局/多行标志**，必须写完整匹配逻辑（即从头到尾）。
- 必须以
^开头、$结尾，否则部分匹配就放行 - 推荐用
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$—— 覆盖常见邮箱结构，排除空格、中文、连续点等 - 不要盲目套用“最全 RFC 正则”，过长会卡 UI，且多数邮箱服务端本身也不严格遵循 RFC
- 移动端键盘可能因
pattern自动切出 @ 符号，这是加分项
inputmode="email" 和 autocomplete="email" 别漏加
这两个属性不参与校验，但影响体验和兼容性：
-
inputmode="email"告诉虚拟键盘优先显示 @ 和 . 键，iOS/Android 都支持 -
autocomplete="email"触发浏览器自动填充，避免用户手输错误；若不用，某些浏览器（如 Safari）会降级为text模式导致pattern失效 - 两者要和
type="email"同时存在，缺一不可
服务端仍需独立校验，前端只是第一道过滤
任何前端校验都可被绕过。真实场景中，用户可能禁用 JS、手动改 DOM、或用 curl 直接 POST。
立即学习“前端免费学习笔记（深入）”；
- 服务端收到
email字段后，必须重新解析：检查格式、DNS MX 记录（可选）、长度（最长 254 字符）、编码（ASCII-only） - 别信前端传来的
value，哪怕它过了pattern和浏览器内置校验 - 特别注意国际化邮箱（如含
ü或张@example.com）——它们需先转为 Punycode 再校验，但绝大多数业务其实不该接受这类邮箱
autocomplete 属性缺失导致的 pattern 失效，以及服务端完全复用前端正则——这两处一出问题，验证就形同虚设。 
