仅用 type="email" 不够，因它只做基础结构检查（含一个@且前后非空），不校验语义有效性、不实时触发、不处理零宽字符；需配合 required、inputmode="email"、autocomplete="email" 及 JS 补救。
浏览器原生 type="email" 能拦住明显错误（比如没 @、只有 @、前后空白），但不能替代 JS 校验或后端验证；它只是个体验层的辅助，不是安全层的防线。
为什么只用 type="email" 不够用
它只做最基础的结构检查：必须含一个 @，@ 前后都得有非空字符（a@b.c 通过，@example.com 或 user@ 不通过）。但它不拒绝 test@localhost、a@b.c 这类 RFC 合法但实际无效的格式；Safari 可能放过 user@domain（缺顶级域），Chrome 对 user@.com 也不报错。更重要的是：校验只在 form.submit() 或点击 type="submit" 时触发，不是实时的，用户粘贴带零宽空格（U+200B）的邮箱也完全无感。
required + inputmode="email" + autocomplete="email" 必须一起上
单独写 <input type="email"> 在 Safari 中可能退化成 type="text"，键盘不弹 @ 键，语义识别失效。要确保基础体验稳定：
-
required是启用浏览器默认必填提示的开关，没它，空值也能过提交 -
inputmode="email"明确告诉移动端用邮箱键盘（iOS/Android 都认） -
autocomplete="email"帮助 Safari 和 Chrome 正确关联字段语义，避免自动补全降级 - 别漏
placeholder，比如placeholder="name@domain.com"，减少用户输错格式的概率
pattern 属性怎么写才不踩坑
pattern 是叠加校验，不是替代 type="email"；写错反而会禁用原生邮箱逻辑（如拼写检查、自动补全）。iOS Safari 完全忽略 pattern，所以不能只靠它。
立即学习“前端免费学习笔记（深入）”；
- 正则必须覆盖整个字符串，浏览器自动加
^和$，别自己再写 - 连字符
-要放在字符类开头或结尾，否则被当成范围符，例如[a-z-]合法，[a--z]报错 - 推荐写法：
pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}" -
title属性必须存在，否则 Chrome 不显示自定义提示文字
JS 补救的关键三步
原生校验漏掉的点，得靠轻量 JS 拦住：粘贴脏字符、前后空格、提交前最终确认。
- 提交前手动
trim()：emailInput.value = emailInput.value.trim() - 主动调用
checkValidity()判断状态，比手写正则更准（它包含浏览器所有内置规则） - 出错时用
reportValidity()触发原生气泡提示，不用自己写 DOM 提示 - 监听
oninput而非仅onblur，避免用户粘贴后直接点提交跳过反馈 - 用
event.target.validity.valid获取最终校验结果，比re.test()更稳
真正容易被忽略的，是本地开发时的 dev@host 或 test@localhost——它们能过原生校验，但会被严格正则干掉；如果测试流程依赖这类地址，别把正则塞进 pattern，而是留到 JS 层做分支判断，或者干脆交给后端兜底。
