type="email"仅做基础格式校验（含@且前后非空），不验证域名存在性、长度或RFC合规性，必须配合required、JS补救（如trim和reportValidity）及后端二次校验。
用 type="email" 是最简方式，但别指望它能拦住所有错误邮箱
浏览器原生的 type="email" 会触发基础格式检查（比如必须含 @、不能有空格），输入不合法时调用 checkValidity() 返回 false，提交时也会阻止表单发送。但它不验证域名是否存在、不校验长度上限、也不识别像 "test@sub.example.co.uk" 这类合法但长尾的结构。
常见误用是只靠它就上线——结果收到一堆 user@domain（缺后缀）、@example.com（缺用户名）甚至 admin@@example.com（双 @）的脏数据。
- 必须配合后端再次校验，前端只是体验优化
- 不要用
pattern覆盖默认行为，容易破坏可访问性（如屏幕阅读器提示） - 若需自定义提示文案，改
setCustomValidity()，而不是重写整个验证逻辑
手动触发校验时，优先用 reportValidity() 而非 checkValidity()
checkValidity() 只返回布尔值，不显示错误气泡；而 reportValidity() 既校验又自动弹出浏览器默认提示（含定位到字段、高亮边框），用户体验更连贯。
典型场景：用户点击「下一步」按钮但没填邮箱，或离开邮箱输入框（blur）时即时反馈。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 在按钮
click事件里直接调用document.getElementById('email').reportValidity() - 如果返回
false，说明校验失败，后续逻辑（如发请求）应中止 - 注意：Safari 15.4+ 才完整支持
reportValidity()在所有表单控件上的表现
需要更强控制力？用 input 事件 + 正则做实时反馈，但别过度
正则 /^[^\s@]+@[^\s@]+\.[^\s@]+$/ 比原生校验稍严（排除了开头/结尾空格和连续 @），适合加在 input 事件里做视觉反馈（如图标变色、提示文字切换）。
但别用它替代提交前的最终校验——正则再复杂也覆盖不了所有 RFC 5322 合法邮箱，且易误杀（比如带 + 的 Gmail 别名 user+tag@gmail.com）。
- 仅用于增强体验：输入过程中标红/绿，不阻止用户继续输入
- 避免每键都执行复杂正则，可用防抖（如延迟 300ms）减少计算
- 真正关键的过滤（如剔除明显无效字符）应在后端做，例如拒绝含
\x00、换行符或控制字符的输入
服务端校验才是底线，前端只是“善意提醒”
任何前端校验都能被绕过——禁用 JS、用 cURL 直接 POST、甚至改 DOM 属性。所以后端必须独立验证：filter_var($email, FILTER_VALIDATE_EMAIL)（PHP）、email-validator（Python）、或至少用正则 ^.+@.+\..+$ 做初筛。
真正容易被忽略的是：校验通过后，还得发确认邮件。因为 user@valid-domain.com 格式再对，也不能保证该邮箱真实存在或由当前用户控制。
- 别省略 DNS MX 记录检查（可选但推荐），能提前发现
@example.invalid类假域 - 长度限制建议设为 254 字符（RFC 5321 规定邮箱总长上限）
- 若业务允许，优先走 OAuth 登录（如 Google、GitHub），绕过邮箱格式问题本身
