HTML原生type="email"验证不靠谱但够用，仅检查基础格式如@和点，不查域名存在性、不防伪造，用户可轻易绕过，绝不能替代后端校验。
HTML原生type="email"验证靠不靠谱
不靠谱，但够用——它只检查基础格式（比如有没有@、有没有点），不发请求、不查域名是否存在、不防伪造邮箱。浏览器会拦截表单提交并弹出提示，但用户右键“检查元素”就能删掉required或改type绕过。
常见错误现象：test@.com、user@@domain.com会被拦，但me@localhost、admin@mail.这种明显无效的也能通过；Safari对email类型支持较弱，甚至忽略pattern属性。
- 仅用于前端快速反馈，绝不能替代后端校验
- 别依赖
:valid伪类做关键状态判断，CSS样式可能被绕过 - 如果要兼容老IE（
type="email"不识别），它会退化成text，此时需JS补位
用pattern加强前端校验时怎么写正则
别抄网上那些号称“RFC 5322 全兼容”的长正则——它们在pattern里基本失效，而且会导致iOS Safari直接忽略整个属性。用简短、可读、覆盖主流邮箱结构的就行。
推荐写法：pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"（注意：必须小写，pattern默认区分大小写）
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 开头
[a-z0-9._%+-]+覆盖常见用户名，不含中文和空格 -
@后面允许子域名（a.b.c.example.com），所以用[a-z0-9.-]+ - 末尾强制以点+至少两个字母结尾，排除
user@domain.c这种无效情况 - 不要加
^和$——pattern自动锚定首尾
JavaScript手动验证时input.checkValidity()和正则谁优先
先调checkValidity()，再补正则。因为原生验证已处理了空值、required、type="email"基础规则，重复用JS正则反而可能漏掉这些约束。
典型错误：监听input事件时，每次输入都跑一遍复杂正则，导致输入卡顿；或没等用户输完就报错（比如刚敲a@就标红）。
- 只在
submit事件或显式点击“提交”时触发完整校验 - 若需实时反馈，用
blur事件比input更合理 - 后端返回邮箱格式错误时，别只改提示文字——同步调用
setCustomValidity("...")，否则checkValidity()仍返回true
后端验证失败后，如何让前端表单重新进入“未通过”状态
光清空input.value或改innerHTML没用。浏览器内部的validity状态不会自动重置，下次调checkValidity()还是true。
正确做法是调用setCustomValidity()设非空字符串，再立刻设为空字符串触发重校验：
input.setCustomValidity("邮箱已被注册");
input.reportValidity(); // 触发显示
// 后续用户修改后，需手动清除：
input.addEventListener("input", () => {
input.setCustomValidity("");
});
- 别用
input.validity.valid = false——这是只读属性，赋值无效 -
reportValidity()会触发原生气泡提示，但无法自定义位置和样式 - 如果用了第三方UI库（如Element Plus、Ant Design），它们的表单组件通常封装了这套逻辑，此时应走组件API而非直接操作DOM
+gmail.com别名，后端却按字面存储并去重，结果me+work@gmail.com和me@gmail.com被当成两个邮箱。这类问题不会报错，只会悄悄导致业务逻辑偏差。 
