type="email"仅校验基础格式，无法限制后缀；需用pattern属性配合正则实现前端白名单，或监听input事件实时验证，但后端必须二次校验且为唯一可信源。
为什么 type="email" 不能满足后缀匹配需求
浏览器原生的 type="email" 只校验基础格式（如是否含 @、是否有域名），对后缀（如只允许 @company.com）完全不干预。提交时仍可能传入 user@gmail.com 这类非法邮箱，后端还得兜底——这不是真校验，只是“看起来像”。
用 pattern 属性做前端后缀白名单
pattern 是最轻量、无需 JS 就能拦截的方案，但要注意：它只在表单提交（或调用 checkValidity()）时触发，且正则必须全匹配（隐式加 ^ 和 $）。
例如只允许 @example.org 或 @example.com：
<input type="email" pattern="^[^\s@]+@example\.(org|com)$" title="仅支持 @example.org 或 @example.com">
-
^[^\s@]+防止空格和连续 @，比.*更安全 - 域名部分用
\.转义点号，避免误匹配@exampleorg -
title是必填项，否则 Chrome 不显示提示 - 不兼容 IE10 及以下；Safari 对
pattern的错误提示较弱
用 addEventListener('input') 实时校验并反馈
仅靠 pattern 用户要到提交才看到错误，体验差。监听 input 事件可即时标记非法输入，但注意别过度干扰用户输入节奏。
示例逻辑：
const emailInput = document.querySelector('input[name="email"]');
const allowedDomains = ['@company.com', '@corp.internal'];
<p>emailInput.addEventListener('input', () => {
const value = emailInput.value.trim();
const atIndex = value.lastIndexOf('@');</p><p>if (atIndex === -1 || atIndex === value.length - 1) return;</p><p>const domain = value.slice(atIndex);
const isValid = allowedDomains.some(d => domain === d);</p><p>emailInput.setCustomValidity(isValid ? '' : '邮箱后缀不合法');
});</p>
- 用
lastIndexOf('@')处理带 + 号的邮箱（如user+tag@company.com） -
setCustomValidity('')清空错误，否则后续校验会被锁定 - 不要在
input里直接alert或修改value，会打断输入流 - 该逻辑需配合
required和type="email"使用，覆盖格式与后缀双重检查
后端必须二次校验，且不能依赖前端正则
前端所有校验都可绕过：禁用 JS、改 DOM、curl 直接发包……所以后端收到 email 字段后，必须独立解析域名并比对白名单。
例如 Node.js 中：
function isValidDomain(email, allowed) {
const match = email.match(/@([^\s@]+)$/);
if (!match) return false;
return allowed.includes(match[1]);
}
// 注意：这里比前端更严格——不信任任何客户端传来的正则结果
- 前端正则写错（比如漏转义
.）会导致漏放行，但后端出错就是安全漏洞 - 如果后缀列表动态变化（如租户配置），前端缓存的
allowedDomains可能过期，后端才是唯一可信源 - 邮件发送前再查一次 DNS MX 记录？没必要。后缀匹配是业务规则，不是送达性验证
真正容易被忽略的是：前后端白名单字符串必须完全一致（大小写、有无点号、是否带 @），一个空格差异就导致合法邮箱被拒。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
