最近在维护一个订单系统表单里联系电话字段被用户投诉了好几轮。明明填了0755-12345678这种标准座机号系统却提示格式错误而123-12345678这种明显不合理的号码反倒能提交成功。定位半天问题就出在JS固定电话正则写得不够细致区号没做约束、分隔符只考虑了短横线、分机号直接没处理。今天把这块经验完整整理出来从最常见的固定电话格式讲起到一份可以直接抄进项目里的正则表达式再到上线之后我踩过的几个真实大坑。1. 先搞清楚要匹配什么固定电话的常见形态写正则之前最忌讳的事就是上来就写\d{3,4}-\d{7,8}。正则的本质是对业务规则的抽象表达业务规则没理清正则写得再漂亮也是错的。所以我先花点时间捋一下国内固定电话到底长什么样。1.1 一个座机号由哪几部分组成一个完整的国内固定电话由三块组成区号以0开头后面跟2到3位数字整体长度是3到4位。比如010、021这种三位区号以及0755、0312这种四位区号。本地号码7到8位数字。不同城市不一样但业务上基本都能用\d{7,8}覆盖。分机号通过分隔符连接常见是1到5位数字。不是每个座机都有分机所以整个分机部分应该是可选的。用户在实际填写时格式比我们想象的丰富得多。区号可能加括号变成(010) 12345678连接符可能用空格也可能什么都不写直接01012345678。更麻烦的是分机号有人写-1234有人写转1234还有人用12345678分机123这种描述。1.2 主流格式和要不要带区号的取舍先把最常见的几种输入形态列出来格式示例说明010-12345678最标准三位区号加短横线0755-12345678四位区号加八位号码(010) 12345678括号区号加空格0312-1234567四位区号加七位号码010-12345678-1234带分机号0755 12345678用空格做分隔符这里有一个业务取舍要提前做要不要接收不带区号的本地座机号。很多内部系统只要求填12345678这种七位或八位号码但从校验角度我不建议把无区号和带区号混在同一个正则里。原因很直接/^\d{7,8}$/会把QQ号、银行账号、一堆乱七八糟的数字串全部放行等于没校验。更合理的做法是默认要求带区号本地号码单独走一个规则互不干扰。提示如果你的业务确实允许用户不填区号别改一个正则去兼容而是用两个正则分别校验这样错误提示也能区分开请填写完整区号和本地号码格式不正确是完全不同的两个提示文案。2. 正则一步一步长这样五个版本的演进对比我比较推荐用演进的方式来写正则每加一个需求就动一次正则别想着一步到位。这样每个符号的作用都很清楚后面维护的人包括三个月后的自己也能看懂当初为什么这么写。2.1 第一版先把骨架搭起来const basicRegex /^\d{3,4}-\d{7,8}$/; console.log(basicRegex.test(010-12345678)); // true console.log(basicRegex.test(0755-12345678)); // true console.log(basicRegex.test(123-12345678)); // true问题出在这里第一版的问题非常明显\d{3,4}匹配的是任意3到4位数字所以123-12345678这种区号完全不合理的号码也能通过。这个版本只能算骨架明白结构长什么样但绝对不能上生产。2.2 第二版区号必须0开头const areaRegex /^0\d{2,3}-\d{7,8}$/; console.log(areaRegex.test(010-12345678)); // true console.log(areaRegex.test(0755-12345678)); // true console.log(areaRegex.test(123-12345678)); // false关键改动就一个0\d{2,3}。这个表达式读起来是一个0后跟2到3位数字对应到业务上正好是以0开头的3到4位区号。010就是0加100755就是0加755。如果你对区号规则比较较真可以更严格一点写成0[1-9]\d{1,2}这样区号的第二位不可能是0或1。但要注意一个例外010的第二位就是1所以这个写法会把北京区号排除掉。实际项目中0\d{2,3}基本够用区号合法性一般靠数据表去校验而不是靠正则穷举。2.3 第三版兼容括号和空格用户不会按标准格式填写这是铁律。第三版把括号区号和空格分隔都接进来const flexibleRegex /^(?:\(0\d{2,3}\)|0\d{2,3})[\s-]?\d{7,8}$/; console.log(flexibleRegex.test(010-12345678)); // true console.log(flexibleRegex.test((010) 12345678)); // true console.log(flexibleRegex.test(0755 12345678)); // true这版的核心是(?:\(0\d{2,3}\)|0\d{2,3})用分支|把带括号和不带括号两种情况都列出来。注意这里用的是(?:...)非捕获组而不是普通的(...)原因后面专门讲。[\s-]?表示连接符要么是空格要么是短横线也可以没有。2.4 第四版接住分机号分机号是固定电话里最容易被忽略的部分。添加分机支持后正则变成const extensionRegex /^(?:\(0\d{2,3}\)|0\d{2,3})[\s-]?\d{7,8}(?:[\s-]?\d{1,5})?$/; console.log(extensionRegex.test(010-12345678-1234)); // true console.log(extensionRegex.test(0312-1234567-12)); // true分机号短也没关系 console.log(extensionRegex.test(010-12345678)); // true分机部分(?:[\s-]?\d{1,5})?整体用?包起来表示可选。[\s-]?负责处理分机号前的分隔符。这里我故意把分机位数放宽到\d{1,5}因为实际业务中真有人填2位分机号你要是写成\d{3,5}人家好好的分机直接被判非法体验很差。2.5 最终版本和更严格的校验函数综合所有需求之后我项目里落地的最终版本长这样const LANDLINE_REGEX /^(?:\(0\d{2,3}\)|0\d{2,3})[\s-]?\d{7,8}(?:[\s-]?\d{1,5})?$/; function isLandline(input) { return LANDLINE_REGEX.test(String(input).trim()); }这个版本能覆盖010-12345678、0755-12345678、(010) 12345678、0312-1234567-1234、0755 12345678。如果你的业务对区号和号码位数有强要求比如三位区号必须配八位号码可以在正则外面再做一层判断const THREE_DIGIT_AREA_CODES new Set([010, 020, 021, 022, 023, 024, 025, 027, 028, 029]); function isLandlineStrict(input) { const value String(input).trim(); const match value.match(/^(?:\(0(\d{2,3})\)|0(\d{2,3}))[\s-]?(\d{7,8})(?:[\s-]?(\d{1,5}))?$/); if (!match) return false; const areaCode match[1] ? 0 match[1] : 0 match[2]; const number match[3]; if (THREE_DIGIT_AREA_CODES.has(areaCode) number.length ! 8) { return false; } return true; }三位区号的城市基本就上面Set里那10个其余地区都是四位区号。这套严格版适合做地址库或CRM系统的二次校验普通表单用前面的宽松版就够了。五个版本放一起对比更直观版本正则核心能匹配明显缺陷骨架版^\d{3,4}-\d{7,8}$010-12345678区号无0开头约束0开头版^0\d{2,3}-...0755-12345678不支持括号、空格、分机灵活版(?:\(0\d{2,3}\)|0\d{2,3})(010) 12345678不支持分机扩展版加(?:[\s-]?\d{1,5})?010-12345678-1234已经比较完整严格版函数内再判断区号位数010-12345678代码量增加3. 每个符号都有讲究正则细节拆解初学者最容易犯的毛病是抄一个正就能用坏了不知道改哪里。正则这东西每个符号背后都有业务逻辑拆开讲清楚比直接甩结论有用得多。3.1 为什么区号写0\d{2,3}而不是\d{3,4}\d{3,4}匹配的是3到4位任意数字它不关心第一位是不是0。而国内固定电话区号有一个硬性特征必须以0开头。所以0\d{2,3}读作0开头后面2到3位数字直接就把123-12345678这类脏数据挡在门外。有人问那写成0[1-9]\d{1,2}不是更严谨吗从区号分配规则来说确实更严谨区号第二位一般不会是0或1010是历史遗留。但我觉得正则要解决的只是格式是否合法区号到底存不存在应该交给数据校验层去查表正则里强行做太细反而增加维护成本。合适的粒度才是好正则。3.2 非捕获组(?:)的实用价值这是我强烈建议所有写正则的人养成习惯的一点。看这两行// 用普通括号 const m1 010-12345678.match(/(\(0\d{2,3}\)|0\d{2,3})[\s-]?(\d{7,8})/); // m1[1] 可能是 (010) 或 010m1[2] 才是本地号码 // 用非捕获组 const m2 010-12345678.match(/(?:\(0\d{2,3}\)|0\d{2,3})[\s-]?(\d{7,8})/); // m2[1] 直接就是 12345678普通括号(...)会生成捕获组match返回的数组里会多出几个元素replace里的$1、$2引用也会跟着乱。非捕获组(?:...)只负责分组不参与捕获让真正需要捕获的内容索引保持稳定。在正则里能用非捕获组的地方尽量别用捕获组这是所有老手的共识。3.3 连字符转义与字符组里的位置陷阱-在正则的字符组[]外并没有特殊含义直接写-也能匹配到短横线。但我建议养成写\-的习惯理由很实际看代码的人第一眼可能分不清这个-是想匹配短横线还是想表达从哪到哪的范围。在字符组[]里-的位置就有讲究了。[\s-]把-放在最后它就是一个普通字符但如果你写成[-\s]虽然也能工作可一旦后面加内容变成[a-z\s]-瞬间变成了范围连接符。最稳妥的写法是永远把-放在字符组的开头或结尾/[\s-]?/ // 推荐- 在末尾 /[-\s]?/ // 也可以但可读性差一点 /[a-z]/ // 这时候 - 是范围不是字符3.4 test()带g标志的隐蔽Bug这可能是整篇文章里最值钱的一个坑。看这段代码const regex /^\d{7,8}$/g; console.log(regex.test(12345678)); // true regex.lastIndex; // 8 console.log(regex.test(12345678)); // false因为 lastIndex 已经被改到末尾正则对象加了g标志之后test()方法会维护一个lastIndex上次匹配到哪下次就从哪开始。同一个正则对象在校验函数里被调用两次第一次返回true第二次就可能返回false而且这种Bug不是必现的非常难排查。解决办法很粗暴做表单校验时正则永远不要加g标志。g标志只在match()、replace()这类需要全局处理的方法里才需要。如果你希望正则复用用const声明且不加g就可以放心多次调用test()。3.5 文本提取时的正向断言和反向断言当你要从一段文本里提取座机号而不是校验整个字符串时情况又变了。直接match加g很容易出现子串误匹配——比如文本里有个8010-12345678标准正则可能会从第二个字符开始匹配出010-12345678。解决方案是用断言卡住边界const extractRegex /(?!\d)(?:\(0\d{2,3}\)|0\d{2,3})[\s-]?\d{7,8}(?:[\s-]?\d{1,5})?(?!\d)/g; const text 联系010-12345678或0755-12345678备用8010-12345678; const matches text.match(extractRegex); console.log(matches); // [010-12345678, 0755-12345678](?!\d)是负向后行断言表示前面不能是数字(?!\d)是负向前行断言表示后面不能是数字。注意后行断言是ES2018才支持的语法如果你的项目还要兼容老版本浏览器或旧安卓WebView就别用(?!\d)。替代方案是正常match之后再用indexOf拿到每个匹配项的位置手工检查前一个字符和后一个字符是不是数字效果一样只是代码多一点。4. 把正则真正放进项目校验、提取、脱敏与格式化正则写出来只是第一步。实际项目里同一个座机号要面对表单校验、数据清洗、展示脱敏、存储格式化这些完全不同的场景。下面这几种写法都是我直接抄进生产项目里用过的可以放心参考。4.1 表单校验的完整写法表单校验最容易遗漏的是trim()。用户从输入框里复制粘贴一个号码前后很可能带着看不见的空格直接test()必然失败。所以标准写法是先清理再校验const LANDLINE_REGEX /^(?:\(0\d{2,3}\)|0\d{2,3})[\s-]?\d{7,8}(?:[\s-]?\d{1,5})?$/; const MOBILE_REGEX /^1[3-9]\d{9}$/; function validateContact(value) { const input String(value).trim(); if (!input) return 请输入联系电话; if (LANDLINE_REGEX.test(input) || MOBILE_REGEX.test(input)) return ; return 联系电话格式不正确座机示例010-12345678; }如果表单允许手机号和座机号都填最好分开校验因为错误提示可以更精准手机号格式不对和座机号格式不对是两种完全不同的体验。千万别图省事写一个正则同时匹配两者维护起来全是坑。4.2 从一段话里批量提取座机号我在做客户留言解析时遇到过需求用户可能在备注里写请打0755-12345678联系我或者传真010-12345678转1234。正则加g标志批量提取就行function extractLandline(text) { const regex /(?!\d)(?:\(0\d{2,3}\)|0\d{2,3})[\s-]?\d{7,8}(?:[\s-]?\d{1,5})?(?!\d)/g; const matches String(text).match(regex) || []; return [...new Set(matches)]; // 去重 }返回结果用Set去重很有必要因为同一段文本里同一号码可能出现多次提取出来做匹配时重复项会导致下游逻辑出问题。另外记得match找不到结果会返回null用|| []兜底是常规操作。4.3 座机号脱敏怎么处理客服工单系统里经常要把座机号打码后展示给非授权人员。脱敏逻辑通常是区号保留本地号码保留开头几位中间打码。八位和七位号码长度不一样所以最好分开处理function maskLandline(phone) { const value String(phone).trim(); const match8 value.match(/^((?:\(0\d{2,3}\)|0\d{2,3})[\s-]?)(\d{3})\d{5}$/); if (match8) return match8[1] match8[2] *****; const match7 value.match(/^((?:\(0\d{2,3}\)|0\d{2,3})[\s-]?)(\d{3})\d{4}$/); if (match7) return match7[1] match7[2] ****; return value; } console.log(maskLandline(0755-12345678)); // 0755-123***** console.log(maskLandline(0312-1234567)); // 0312-123****这种写法依赖捕获组$1拿区号前缀、$2拿前三位号码然后手动拼上星号。比在正则里直接做替换更直观也更好控制保留位数。4.4 多种输入统一格式化的实现存储座机号之前最好把用户输入的千奇百怪格式统一成标准形式。我常用的转换函数长这样function normalizeLandline(phone) { const value String(phone) .trim() .replace(/[-]/g, (char) String.fromCharCode(char.charCodeAt(0) - 0xFEE0)); const match value.match(/^\(?0(\d{2,3})\)?[\s-]?(\d{7,8})(?:[\s-]?(\d{1,5}))?$/); if (!match) return value; return 0 match[1] - match[2] (match[3] ? - match[3] : ); } console.log(normalizeLandline((010) 12345678)); // 010-12345678 console.log(normalizeLandline(0755 12345678)); // 0755-12345678 console.log(normalizeLandline(0312-1234567-1234)); // 0312-1234567-1234注意match[1]捕获的是区号里0后面的数字拼上去的时候要手动补回0。这套转换在数据入库前跑一遍后续查询统计都会省心很多。5. 真正上线后的踩坑记录这些坑排错排到怀疑人生正则本身写对不代表线上就不会出事。下面这几个问题全是真实环境里碰到的每一个都值得记进自己的排查清单。5.1 全角数字和全角横杠移动端输入法默认全角模式的时候用户会输入这种看起来完全正常的号码。\d只能匹配ASCII数字全角数字直接校验失败。最省事的处理方式是用normalize(NFKC)一键把全角字符转成半角.normalize(NFKC); // 0755-12345678如果不方便用normalize也可以用字符码偏移str.replace(/[-]/g, (char) String.fromCharCode(char.charCodeAt(0) - 0xFEE0));全角横杠也建议在预处理阶段统一替换成半角-否则正则里的[\s-]根本匹配不到。5.2 移动端自动填充带来的意外格式给input typetel autocompletetel做校验时浏览器自动填充可能会填出各种意外格式带国家码的86 0755 12345678、带括号的(0755) 12345678甚至把姓名、邮箱一起塞进来。解决思路是先洗净再校验function cleanPhoneInput(value) { return String(value) .trim() .replace(/^\?86[\s-]?/, ) // 去掉86或86前缀 .replace(/[-]/g, (char) String.fromCharCode(char.charCodeAt(0) - 0xFEE0)); }如果业务上确实需要支持86那就在主正则前面加一段(?:\?86[\s-]?)?两种策略都可以但一定要在项目里明确写清楚不然下次接手的同事会一脸懵。5.3 手机号、座机号和parseInt的几个边界手机号是1开头座机号是0开头这两种号码在正则层面天然不会混淆但业务层容易出问题。比如联系电话字段既允许手机又允许座机时很多人会先判断/^1\d{10}$/不是手机号再判断座机正则。这里有个小陷阱如果你的手机号正则写成/^1\d{10}$/那么010-12345678不会被误判成手机号但某些比较老的号码段如果不小心写成/^1[3-9]\d{9}$/之外的形式可能两头都不匹配。还有一个和正则无关但和号码处理强相关的坑别用parseInt处理电话号码。parseInt(010)在部分环境下会得到10八进制解析甚至直接报错。电话号码处理永远走字符串方法slice、replace、match都可以就是别转数字。5.4 400/800电话别和座机号混在一起校验如果业务涉及客服系统用户可能填400-123-4567这类企业服务热线。注意这不是传统意义上的固定电话不该混进同一个座机正则里。混在一起的结果就是校验规则越来越复杂最后谁都维护不了。我一般会单独建一个正则const SERVICE_LINE_REGEX /^400[\s-]?\d{3}[\s-]?\d{3,4}$/;然后在校验函数里按顺序判断400热线、800热线、座机、手机各走各的规则。号码类型直接分清楚比在一个正则里堆|分支要清晰得多。5.5 前后端正则不一致的教训最后分享一个让我印象深刻的线上事故。前端表单用的是\d{7,8}做校验后端Java接口用的是\d{7}结果所有7位号码都没问题8位号码前端放行、后端拦截用户提交之后就卡在系统繁忙的提示上。排查到最后才发现是前后端两套正则位数不一致。现在的做法是同一个正则规则在项目里只维护一份前端JS、后端Java各自引用同一份规则描述至少要把正则的版本号和允许格式写在注释里。我甚至会为核心校验函数写几个固定用例const testCases [ [010-12345678, true], [0755-12345678, true], [0312-1234567, true], [010-1234567-1234, true], [123-12345678, false], [01012345678, true] ];每次改了正则把这组用例跑一遍再提交。正则这种写的时候很爽、维护的时候想哭的东西有测试用例兜底比什么经验都管用。这五个方向的坑每一个都对应着真实用户输入和线上故障。座机号这个字段看似不起眼做细了能省掉大量客服解释成本。写正则的底线是宁可严格一点让用户补全格式也不要宽松到把脏数据放进系统里。
