input[type="email"]单独使用不可靠，需组合required、autocomplete、inputmode等属性，辅以JS trim和checkValidity()校验，并依赖后端统一清洗与验证。
直接用 input[type="email"] 就能触发浏览器原生邮箱校验，但只靠它远远不够——它拦不住 user@.com、test@localhost，也管不了粘贴进来的零宽空格（U+200B），更不会告诉你“该邮箱已被注册”。真正可用的验证，得靠属性组合 + 轻量 JS 补救 + 后端兜底。
为什么 input[type="email"] 单独用会失效
它只是个“软开关”：Chrome 里 user@domain（缺后缀）会被拦，但 Safari 可能放行；a@b.c 在所有浏览器都算“合法”，尽管现实中根本发不出邮件。关键问题在于校验时机和规则粒度：
- 只在
form.submit()或点击type="submit"按钮时触发，不是实时的 - 不自动
trim()，用户输入" user@example.com "（首尾空格）可能通过校验 - IE9 及以下完全忽略该类型，退化为普通
text - pattern 属性在 iOS Safari 中被无视，不能当主力用
required、autocomplete、inputmode 必须配齐
单写 type="email" 是裸奔。这几个属性不是可选项，是基础防线：
-
required：启用必填提示，但注意——它只检查是否为空字符串，不处理空格 -
autocomplete="email"：告诉浏览器这是邮箱字段，Safari 才不会把它当普通文本框降级 -
inputmode="email"：明确提示移动端弹出带 @ 和 . 的键盘，比单纯靠type更稳 -
placeholder="name@domain.com"：视觉引导，减少用户输错格式的概率
漏掉任意一个，都可能让原生校验在某个平台静默失效。
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
用 checkValidity() + reportValidity() 做轻量 JS 补救
不要重写正则来替代原生逻辑，而是用浏览器自己的判断结果，再加一层清洗：
- 提交前手动
trim()：emailInput.value = emailInput.value.trim() - 调用
emailInput.checkValidity()获取布尔结果，比手写正则更准（它包含浏览器对type="email"的全部实现细节） - 失败时主动
emailInput.reportValidity()触发气泡提示，避免用户点提交才第一次看到错误 - 监听
input事件而非仅blur，防止用户粘贴完直接点提交跳过反馈
示例片段：
emailInput.addEventListener('input', () => {
emailInput.value = emailInput.value.trim();
});
form.addEventListener('submit', (e) => {
if (!emailInput.checkValidity()) {
emailInput.reportValidity();
e.preventDefault();
}
});
后端验证不是“补充”，而是唯一可信环节
前端所有校验都可被绕过：禁用 JS、改 DOM、抓包重放……真正决定“这个邮箱能不能用”的，只有后端。重点不在正则多复杂，而在数据流转是否干净：
- 服务端收到邮箱后，必须先
trim()再转小写，否则User@EXAMPLE.COM和user@example.com会被当成两个账号 - 别在注册接口同步查 MX 记录——延迟高、易被限频、MX 存在 ≠ 邮箱真实可用
- “是否已注册”的判断，必须走独立接口（如
POST /api/check-email），且要加防抖、限流、CSRF token - 正则别追求 RFC 5322 全集，宽松匹配即可：
/^[^\s@]+@[^\s@]+\.[^\s@]+$/，太复杂的正则在 Node.js/V8 下容易回溯爆炸
真正上线后暴露的问题，往往不是正则写错了，而是前端 trim 了、后端没 trim，或者大小写归一化只做了一半。
