使用 type="email" 可触发浏览器原生邮箱格式校验，验证是否含@和域名，同时调出带@的虚拟键盘；但不验证邮箱真实性，且IE9及以下不支持，需JS回退及服务端双重校验。
用 type="email" 让浏览器自动校验邮箱格式
HTML5 原生支持邮箱格式校验，只需把 input 的 type 设为 "email"，浏览器就会在提交前检查是否符合基本邮箱结构（含 @ 和域名部分）。这不是 JavaScript 模拟，而是原生表单验证机制。
常见错误现象：用户输入 user@ 或 @example.com，点击提交时浏览器会弹出提示（如 Chrome 显示“请填写有效的电子邮件地址”）。
- 仅校验基础格式，不验证邮箱是否真实存在或可送达
- 移动端会自动调出带 @ 符号的键盘，提升输入体验
- 不兼容 IE9 及更早版本（IE10+ 支持）
- 若需兼容旧浏览器，必须配合 JS 回退校验
配合 required 和 pattern 做增强控制
required 保证非空，pattern 可补充更严格的正则约束（比如禁止某些域名、限制长度）。但注意：pattern 在 type="email" 下不会覆盖默认邮箱校验逻辑，而是叠加执行。
例如，禁止使用 qq.com 邮箱：
立即学习“前端免费学习笔记（深入）”；
说明：
-
title属性用于自定义校验失败时的提示文案 -
pattern是正则表达式，必须匹配整个值（隐式加 ^ 和 $） - 浏览器对
pattern的支持度比type="email"略低（IE10+、Edge12+、主流现代浏览器 OK） - 过度依赖
pattern容易写出过于严苛或漏判的正则，比如误拦user+tag@example.com
服务端仍必须校验，前端限制只是辅助
所有 HTML5 表单属性（type、required、pattern）都可被绕过：禁用 JS、修改 DOM、用 curl/postman 直接发请求——这些都会让前端校验完全失效。
所以后端必须独立实现邮箱校验，且建议：
- 用语言标准库解析（如 Python 的
email.utils.parseaddr，Node.js 的validator.isEmail()） - 避免手写复杂正则，RFC 5322 规范中的邮箱格式远超前端能覆盖的范围
- 若需高可靠性，应在注册/重置密码等关键流程中加入邮箱可达性验证（发送确认链接）
不要用 inputmode="email" 替代 type="email"
inputmode="email" 只影响虚拟键盘显示（比如 iOS 弹出带 @ 的键盘），**完全不触发任何格式校验**。它和 type="email" 是两回事，混用也不会增强校验能力。
典型误用场景：
这等于放弃所有 HTML5 邮箱校验，只换来一个友好的键盘——对防错毫无帮助。
真正需要的是明确语义：type="email" 表达“这是邮箱字段”，浏览器据此启用校验、键盘优化、无障碍支持等一整套行为。
