pattern仅对text、email、tel、url等文本类type生效,不适用于number;手机号推荐type="tel"+适配分隔符的pattern;邮箱宜用原生email+业务约束;须用setCustomValidity自定义提示。
直接写 pattern 但没设 type,或者用了 type="number",正则根本不会触发。浏览器只对 type="text"、type="email"、type="tel"、type="url" 等文本类输入生效。
常见错误:用 type="number" 写手机号 pattern —— 用户输完点提交,pattern 完全不校验,因为浏览器已把输入转成数字,且自动过滤非数字字符,正则匹配对象早不是原始字符串了。
type="tel" 最适合手机号,语义正确,移动端弹出数字键盘,且允许 pattern 校验type="email" 自带基础邮箱格式检查,但不够严格;加 pattern 可强化(比如禁止连续点号、开头结尾不能是点)type="text" + 过于宽松的 pattern,比如只写 pattern="[0-9]+",用户仍可粘贴空格或换行符纯 pattern="^1[3-9]\d{9}$" 看似简洁,但会拒绝合法号码:比如带空格/短横线的用户输入(138 1234 5678)、粘贴进来的带括号格式((138)1234-5678),而表单默认不自动清理格式。
更实用的做法是:用 pattern 约束「最终提交值」,同时用 JavaScript 预处理输入(如 oninput 清除空格),或接受带分隔符的输入但 pattern 允许可选分隔符。
pattern="^1[3-9]\d{1,4}[-\u3000\s]?\d{4,8}[-\u3000\s]?\d{4}$"
pattern="^1[3-9]\d{9}$",需配合 inputmode="numeric" 和 JS 清理/g 或 /i 标志,也不写开头结尾的 /,直接写表达式主体原生 type="email" 已能拦截 abc@、@domain.com 等明显错误,再叠一个过于复杂的 RFC 5322 正则(比如上千字符的)反而导致兼容性问题和误判——例如拒绝合法的 user+tag@domain.com 或带下划线的子域名。
真正需要加强的,是业务侧约束:比如禁止 QQ 邮箱、要求企业域名、排除常见临时邮箱域名。
pattern="^[^\s@]+@[^\s@]+\.[^\s@]+$"
pattern="^[^\s@]+@(?!qq\.com$)[^\s@]+\.[^\s@]+$"(注意:pattern 不支持负向先行断言的浏览器会忽略整条规则)type="email" 做初步校验,提交前用 JS 检查 value.split('@')[1] 是否在白名单内浏览器默认报错是“请与所要求的格式匹配”
,用户完全不知道哪里错了。仅靠 title="请输入 11 位手机号" 也不够——title 在部分浏览器中不显示,或只 hover 才出现,移动端基本无效。
真正起作用的方式是监听 invalid 事件,调用 setCustomValidity() 覆盖默认提示。
document.querySelector('input[type="tel"]').addEventListener('invalid', function(e) {
e.target.setCustomValidity('手机号格式不正确,请输入 11 位大陆手机号');
});
document.querySelector('input[type="tel"]').addEventListener('input', function() {
this.setCustomValidity('');
});
注意:每次 input 后必须清空 custom validity,否则后续合法输入仍被阻塞;pattern 校验发生在表单 submit 时,不是实时的。
复杂场景(如动态校验码、用户名唯一性)无法用 pattern 实现,得靠 JS + 后端接口配合,别硬塞到 pattern 里。