正则表达式仅校验格式，不验证真实性；pattern触发原生提示，setCustomValidity()接管文案；后端必须重验。手机号用/^1[3-9]\d{9}$/覆盖主流号段，邮箱推荐^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$，setCustomValidity()后须手动清空否则状态残留。
直接上结论：正则表达式本身不校验号码真实性，只管格式；pattern 属性在 HTML 中仅触发浏览器原生提示，setCustomValidity() 才能接管错误文案；后端必须重验，前端只是体验优化。
手机号验证用 /^1[3-9]\d{9}$/ 就够了，但要注意第二位范围
这个正则匹配 11 位、以 1 开头、第二位是 3–9 的数字串，覆盖当前主流号段（如 13x、15x、18x、19x）。它不处理带空格、括号、短横线的输入（比如 138-0013-8000），也不校验虚拟运营商或已停用号段。
- 如果允许用户输带分隔符的格式，先用
.replace(/[\s\-()]/g, '')清洗再校验 -
type="tel"不会自动触发该正则，必须配合pattern属性才生效 - 注意：iOS Safari 对
pattern支持不稳定，建议 JS 层兜底
邮箱验证别只用 /\w+@\w+\.\w+/，得兼容下划线、连字符和多级域名
简陋正则会漏掉 user_name@sub.domain.co.uk 这类合法邮箱。推荐用：/^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(\.[a-zA-Z0-9_-]+)+$/
- 开头和 @ 前支持字母、数字、
_、- - @ 后至少含一个点，且每段域名都支持上述字符（适配
qq.com、163.com.cn） - 不校验 MX 记录，也不判断邮箱是否真实存在——这是后端 SMTP 探针的事
setCustomValidity() 调用后必须手动清空，否则表单一直卡住
这是最容易踩的坑：一旦给元素调了 input.setCustomValidity('xxx')，即使后续输入合法，只要没再调一次 input.setCustomValidity('')，表单就始终认为该字段无效。
立即学习“前端免费学习笔记（深入）”；
- 常见写法是在
blur或input事件里，校验通过时立刻设为空字符串 - 不要依赖
submit事件统一清理——用户可能中途修改又没失焦，错误状态残留 - Chrome 控制台能看到
ValidityState.customError === true，可用于调试
身份证号正则要区分 15 位老号和 18 位新号，但校验码不能靠正则算
格式层面可用：/^[1-9]\d{5}(19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]$/ 初筛 18 位；/^[1-9]\d{13}[0-9Xx]$/ 匹配 15 位老号。
- 18 位末尾校验码需按国标 GB11643-1999 算权值，正则做不到——必须写函数单独校验
- 地址码前两位（省码）不能为 00，但正则无法穷举所有有效组合，只能靠后端数据库比对
- 出生日期部分（如
20251301）在正则里能拦掉明显非法值，但闰年、大小月等仍需 JS 补充判断
真正难的不是写出正则，而是明确边界：哪些交给正则快速过滤，哪些必须进函数细判，哪些干脆甩给后端查库。漏掉任何一环，都可能让脏数据穿过前端防线。
