email 类型的 input 元素触发浏览器原生基础格式校验：必须含 @ 且前后均有非空字符，不验证域名真实性或邮箱可用性；校验发生在表单提交或调用 checkvalidity() 时，移动端自动切换 email 键盘。
email 类型的 input 元素会触发什么校验？
浏览器原生只做最基础的格式检查：必须包含一个 @ 符号，且前后都有非空字符（比如 a@b 会通过，@example.com 或 user@ 不会）。它不验证域名是否存在、邮箱是否真实可用，也不发 DNS 查询。
常见错误现象：input[type="email"] 在表单提交时突然弹出“请填写有效的电子邮件地址”，但用户明明输了 test@example——这是因为缺少顶级域（如 .com），而浏览器认为这不符合 email 格式规范。
- 校验发生在
form.submit()或点击type="submit"按钮时，不是实时的 - JavaScript 调用
checkValidity()也会触发同一套规则 - 移动端键盘会自动切换为带
@和.的 email 键盘，这是唯一确定的 UX 增益
如何让 email 输入更可靠，又不破坏原生体验？
别绕开 type="email"，但得补一层 JS 校验。原生校验太宽松（放行 me@localhost），又太死板（拒绝带 + 号的合法邮箱如 user+tag@gmail.com）。
推荐做法是保留 type="email" 获取键盘和基础提示，再用正则或库做二次判断：
立即学习“前端免费学习笔记（深入）”；
一套面向小企业用户的企业网站程序！功能简单，操作简单。实现了小企业网站的很多实用的功能，如文章新闻模块、图片展示、产品列表以及小型的下载功能，还同时增加了邮件订阅等相应模块。公告，友情链接等这些通用功能本程序也同样都集成了！同时本程序引入了模块功能，只要在系统默认模板上创建模块，可以在任何一个语言环境（或任意风格）的适当位置进行使用！
- 简单增强：用
input事件监听，配合/^[^\s@]+@[^\s@]+\.[^\s@]+$/过滤明显错的（注意：仍不覆盖所有 RFC 合法情况） - 生产环境建议用
validator.js的isEmail()，它处理了 Unicode、+ 号、引号等边界 case - 服务端永远要重验——前端任何校验都可被绕过
示例：
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(emailInput.value)) {<br> emailInput.setCustomValidity("邮箱格式不对");<br>} else {<br> emailInput.setCustomValidity("");<br>}
为什么 pattern 属性和 type="email" 一起用反而坏事？
两者校验逻辑冲突。type="email" 自带默认 pattern，再加 pattern 会导致浏览器同时运行两套规则，出错提示混乱，甚至掩盖原生的友好提示（比如移动端键盘）。
典型翻车场景：写成 <input type="email" pattern="[a-z]+@example\.com">，结果用户输 test@gmail.com 直接被拦住，连原生的 @ 检查都不走了。
-
pattern仅适用于type="text"、"search"等无内置校验的类型 - 如果真要限定域名，应该在 JS 或服务端做白名单判断，而不是塞进
pattern - 想自定义报错文案？用
setCustomValidity()，别碰pattern
兼容性和无障碍支持要注意什么？
所有现代浏览器都支持 type="email"，IE10+ 也行；真正的问题在读屏软件和旧版 Android WebView —— 它们可能忽略 type，只当普通文本框处理。
- 必须配
aria-describedby指向说明文字，比如“请输入常用邮箱，用于接收验证邮件” - 别依赖 placeholder 当标签，用
<label for="email"></label>显式关联 - 如果项目要支持 IE9 及更早版本，就别用
type="email"，降级为type="text"并靠 JS 补全逻辑
容易被忽略的是：当用户粘贴邮箱时，某些老版本 Safari 不触发 input 事件，导致你写的实时校验失效。保险起见，监听 paste 事件并手动调用校验函数。
