做了这么多年表单验证我一直觉得固定电话校验是个特别容易翻车的小活儿。看似一个正则就能搞定的事真正上线后各种幺蛾子区号带不带0、客户从海外打来带86、分机号用#分隔还是-分隔随便一个变体就能把校验逻辑打穿。这篇文章把我实践过的固定电话验证方案完整拆开聊覆盖区号、号码、分机号三段的规则推导、正则写法和前端落地细节适合正在做用户信息采集、CRM系统、企业通讯录这类功能的同学参考。1. 固定电话验证的整体设计思路1.1 为什么不能无脑套一个正则很多人第一次写固定电话校验直接从网上复制一个“通用正则”过来比如^0\d{2,3}-?\d{7,8}$写了就完事。但真放到业务里你会发现至少几个问题号码里带空格行不行带括号行不行用户输入了分机号怎么办国际用户输国家代码怎么办更麻烦的是业务侧还可能要求你把区号和号码分别存库如果只是做一个整体校验后续拆分还得再写一套逻辑。所以我在处理这类需求时会先把“校验”拆成几层来说第一层格式是否合法——即号码是否符合固定电话的基本结构。第二层业务约束是否通过——比如某些区号不在可呼叫范围内比如分机号位数上限。第三层输入规范化——把用户五花八门的输入空格、括号、横线转成统一的存储格式。这跟做密码校验是一个道理光判断“不为空”和判断“包含大小写字母加数字加特殊字符”完全是两个量级的需求。固定电话验证真正要做的是把“看起来像电话号”和“其实是可用电话号”区分开。1.2 固定电话的三段式结构固定电话和手机最大的区别在于它是“分层”的区号 本地号码 分机号。以中国大陆为例区号以0开头后面跟 3 或 4 位数字例如北京010、上海021、深圳0755、杭州0571。本地号码是 7 或 8 位数字例如12345678、8765432。分机号是拨打总机后继续拨的短号通常是 1 到 6 位数字例如801、1234输入时经常用-、#或中文“转”字连接。如果把这三段拆开看每一段的规则其实都不算复杂难的是如何组合成一个既严格又宽容的表达式。太严用户正常的输入格式会被误杀太宽随便一串数字也能过校验就失去了意义。1.3 明确适用场景别把需求做偏开始写代码之前我强烈建议先确认两件事这个输入框到底要不要接受手机号到底要不要接受国际号码我见过好几次因为需求没说清最后把固定电话规则写得跟手机万能正则一样结果验证形同虚设。固定电话验证的场景通常集中在这些地方企业联系资料录入需要存座机号码方便售后或客服外呼。用户收货信息有的用户就是不留手机只留座机系统需要能存能验。外呼系统白名单校验只允许添加格式正确的座机号码。如果只是做“看起来像座机号”的弱校验可以宽容一点如果要对接外呼线路或短信接口就必须严格按照运营商号段规则来。两者差异很大先确认再动手。2. 区号验证最容易被忽略的严格规则2.1 中国大陆区号的两种长度中国大陆固定电话区号分为 3 位和 4 位两类。3 位区号是各大中心城市包括010北京、021上海、022天津、023重庆、024沈阳、025南京、027武汉、028成都、029西安另外还有020广州。注意026这个号段并没有分配给任何城市早年有传闻说要给台北但实际通信规划中并未启用。4 位区号是 3 位区号以外的其他城市以03xx、04xx、05xx、06xx、07xx、08xx、09xx开头例如0311石家庄、0755深圳、0571杭州。比较坑的一点是如果只用^0\d{2,3}$来校验区号026这种不存在的区号也能通过。更严格的写法应该区分对待(?:010|02[0-9]|0[3-9]\d{2})这里用到了“或”分支010单独列出来02[0-9]匹配 021 到 029顺手排除了 026 这种不存在的号码0[3-9]\d{2}匹配 4 位区号里除 02 外的其他省份开头。这样写能排除大量无效区号并且不增加太多复杂度。2.2 国际区号国家代码要放在最前面如果你的系统面向的是有海外联系人的用户那么验证规则里还得考虑国家代码。国际区号国家代码长度从 1 位到 3 位不等例如美国1、俄罗斯7、英国44、中国86、新加坡65。最宽松的做法是接受或00开头的国家代码前缀(?:\?\d{1,3})?但要小心这个正则如果独立使用后面跟 0 到 3 位数字都能过‘86’可以‘1’可以但‘’单独出现也能过。所以实际使用时要配合后面的区号和号码部分保证国家代码后面必须跟着完整的本地号码。对于中国大陆业务更常见的选择是国家代码只允许86或0086或者完全不接受国家代码。这属于业务规则正则只负责搭建允许的框架。2.3 区号部分的容错写法括号和空格真实用户输入时区号常常被写成这些样子010-12345678(010) 1234567886 10 12345678从体验出发我倾向于让正则同时接受“带横线”“带空格”“带括号”的写法然后统一清洗成标准格式。一个比较顺手的区号正则片段是(?:(?:\?86[\s-]?)?(?:0\d{2,3})|(?:\(0\d{2,3}\)))[\s-]?这段代码允许010中国大陆常见写法0755-区号后带横线(010)括号包裹86 010国家代码 空格 区号86-21国家代码 横线 两位区号在正则里把可选的符号写成两到三种可能比只写死一种格式后续要处理的数据形态会舒服很多。3. 本地号码与分机号的验证细节3.1 本地号码的位数与开头限制本地号码是 7 或 8 位数字但不同城市长度有差异像北京、上海、广州这种大城市通常是 8 位本地号一些中小城市可能是 7 位。如果网络上传输或存储空间有限制可以让验证同时接受两种长度\d{7,8}有些技术方案会要求本地号码不能以0或1开头理由是这样能避免和特殊服务号码撞车。从严谨角度讲有点道理但实际中本地号码开头是 2 到 9 的占绝大多数真去严格限制开头反而容易误伤。我的做法是只限制“位数”不限制“开头数字”靠运营商侧去保证可用性。还有个隐藏细节本地号码可能出现“4 位区号 7 位本地号”和“3 位区号 8 位本地号”的常见组合但也存在“3 位区号 7 位本地号”的历史号码比如部分早期铺设线路的城市。所以不要写成“3 位区号必须配 8 位本地号4 位区号必须配 7 位本地号”那样会拦截掉不少真实可用的号码。3.2 分机号的常见写法分机号是整段验证里最容易因为格式问题被用户吐槽的。现实中分机号长这样-801#123转801空一格再写801写成12345没有分隔符我的推荐是接受“横线”和“#”作为分隔符分机号本身限制为 1 到 6 位数字(?:[-#]\d{1,6})?有人问为什么不支持中文“转”其实是支持的只是转义上比较麻烦。愿意做的话可以加一个(?:转\d{1,6})?。但从存储统一性来看我建议在提交时把“转”字符直接替换成-这样入库数据干净后续导出给外呼系统也方便。3.3 三段拼接完整正则示例把上面的片段拼到一起一个“看起来能打”的固定电话验证正则就出来了^(?:(?:\?86[\s-]?)?(?:0\d{2,3}|\(0\d{2,3}\))|(?:\?\d{1,3})?)[\s-]?\d{7,8}(?:[-#]?\d{1,6})?$解释一下各段(?:\?86[\s-]?)?可选的国家代码86或86后面可带空格或横线。(?:0\d{2,3}|\(0\d{2,3}\))区号允许带括号。[\s-]?区号和本地号之间的分隔符。\d{7,8}本地号码。(?:[-#]?\d{1,6})?可选的分机号。如果业务只针对中国大陆不想允许其他国家代码可以把最外层括号去掉直接写成^(?:\?86[\s-]?)?(?:0\d{2,3}|\(0\d{2,3}\))[\s-]?\d{7,8}(?:[-#]\d{1,6})?$注意分机号这里我把[-#]?改成了[-#]也就是要么不写分机要写就一定要带分隔符。否则“12345678”这种 8 位本地号后面再跟一堆数字容易把本地号和分机号混在一起不利于后面的拆分。4. 前端实操格式校验、自动清洗与号码拆分4.1 输入阶段先做“软校验”很多开发同学把校验逻辑全放在表单提交那一刻用户填错了再弹红字。这个流程体验不好更好的做法是“输入阶段 失焦阶段”双管齐下。输入阶段做两件事过滤非法字符、自动格式化。固定电话框里只允许数字、横线、空格、括号和#那么可以在oninput里直接把其他字符剔除掉input.addEventListener(input, function (e) { let val e.target.value; // 去掉所有非数字、非横线、非空格、非括号、非#的字符 val val.replace(/[^\d\s\-()#]/g, ); e.target.value val; });这能防止用户误输入字母或标点符号从源头减少脏数据。顺手还可以做长度限制比如总长不超过 20 位避免用户粘贴一长串无意义字符。4.2 失焦校验给用户明确的错误提示到失焦时再跑完整正则校验。这里我建议不要只写一个“电话格式不正确”而是分成三种提示区号缺了提示“请填写带区号的固定电话如 010-12345678”。本地号位数不对提示“本地号码通常为 7 到 8 位数字”。分机号格式不对提示“分机号请用-或#分隔如-801”。这样做的好处是用户能快速定位自己错在哪。有人觉得这功能麻烦但在用户资料表单里减少一次提交失败就是减少一次流失。4.3 把“验证”升级为“解析”校验通过后下一步是把用户输入的字符串拆解成区号、本地号、分机号三部分。这一步在做 CRM 导入、通讯录导出时会特别有用毕竟存一个phone字段是全串后续要按区号筛选客户就麻烦了。可以通过正则捕获组来做function parseFixedPhone(input) { const cleaned input.trim().replace(/[()]/g, ); const match cleaned.match(/^(?:\?86)?[\s-]?(0\d{2,3})[\s-]?(\d{7,8})(?:[-#](\d{1,6}))?$/); if (!match) return null; return { areaCode: match[1], // 含0的区号 localNumber: match[2], extension: match[3] || }; }这里我先把括号去掉了因为括号对数据的实际意义不大。然后通过正则捕获组把三段内容分别取出来。返回的对象可以直接用于入库、展示或后续拼接。剥离括号的操作不影响号码准确性但能让数据更规整。4.4 统一存储格式全数字还是带符号数据库里存固定电话我见过两种流派存全数字串例如01012345678。存格式化串例如010-12345678。如果业务侧有很多排序、筛选、去重需求全数字串是更优选择因为不带分隔符比较大小、匹配前缀都简单。如果业务需要“原样回显”那就存格式化串展示时不用再处理。更规范的做法是拆字段存储area_code、local_number、extension各存各的。这样最清晰也能避开“区号要不要带0”的争论——直接存规范化的010需要拼接时再自己拼。缺点是表结构稍微复杂查询时得拼起来再匹配。按我的经验如果这个号码是客户主联系方式拆字段存长期看很值。5. 常见问题与排查技巧实录5.1 400、800电话能不能用固定电话正则校验经常有业务把 400 电话也当成固定电话来录。400 电话的结构是400开头 7 位数字没有区号例如400-123-4567、4001234567。固定电话的区号规则要求以0开头400 不符合所以标准固定电话正则会把它拦掉。如果业务场景里有 400 电话要么单独加一个校验分支要么干脆在表单层面把“固话”和“400 热线”做成两个不同的输入项避免混在一起。我推荐后一种因为 400 号码没有区号和分机的概念硬塞进固定电话规则里会让逻辑变得很拧巴。5.2 用户粘贴进来的号码带一堆多余字符常见的脏数据样例和应对方式010 - 12345678横线前后有空格01012345678全角括号86-010-12345678国家代码和区号都带了001012345678-801区号、本地号、分机号之间没分隔符我的处理顺序是把全角字符转半角。去空格。再跑解析函数。全角转半角可以写个小工具函数把这些映射回 ASCII 对应的字符。如果你嫌麻烦也有现成 npm 包可用不过就一个几行函数的事我一般自己写。5.3 正则没问题但总有个别号码验证失败这种情况八成是“位数正确但区号规则兜不住”。比如 4 位区号的排列不止0[3-9]\d{2}这些实际上部分县区还使用 5 位区号的历史遗留号码在假号码测试时不会遇到但真用户提交时就会遇到。如果一个正则为了覆盖所有历史遗留号码被撑得特别复杂我建议折中主流程用严格正则校验不通过时再做一次宽松正则兜底只提示用户确认而不是直接拒绝。这在用户资料采集场景里体验尤为关键毕竟我们首要目标是不拦错人。5.4 一定要记得做长度上限约束固定电话虽然不会像手机号那样严格限制 11 位但正则一旦写成\d{7,8}如果前面国家代码和区号里还有86整串长度一般在 20 位以内。超过这个长度基本就是用户乱填了。我实际踩过一个坑某个用户从 Excel 里粘贴了一整行数据到一个输入框因为没做长度限制校验正则侥幸通过了一部分最后入到库里一堆残缺号码。后来我强制加了maxlength24并且在前端校验总长度这个问题瞬间消失。6. 最后再分享一些实操心得做固定电话验证这件事说难不难说简单也容易翻车。我现在每次接到这类需求都会先把问题抛回给产品这个号码之后要用来做什么是外呼、是展示、还是存档需求不同校验的严格程度就不同。如果是存档展示我把规则写得温和一点给用户提示而不是强硬拦截。如果是外呼系统那就必须严格按号码规则校验乱填一个根本打不通的号码浪费的是客服人员的时间。另外有一点我想特别提一下正则表达式虽然好用但不要指望一个正则包打天下。前端校验、后端校验、数据库约束三层各司其职前端负责体验后端负责数据安全数据库只负责格式兜底。把这三层都做扎实了固定电话验证这个看似简单的功能才真正耐打。
做了这么多年表单验证我一直觉得固定电话校验是个特别容易翻车的小活儿。看似一个正则就能搞定的事真正上线后各种幺蛾子区号带不带0、客户从海外打来带86、分机号用#分隔还是-分隔随便一个变体就能把校验逻辑打穿。这篇文章把我实践过的固定电话验证方案完整拆开聊覆盖区号、号码、分机号三段的规则推导、正则写法和前端落地细节适合正在做用户信息采集、CRM系统、企业通讯录这类功能的同学参考。1. 固定电话验证的整体设计思路1.1 为什么不能无脑套一个正则很多人第一次写固定电话校验直接从网上复制一个“通用正则”过来比如^0\d{2,3}-?\d{7,8}$写了就完事。但真放到业务里你会发现至少几个问题号码里带空格行不行带括号行不行用户输入了分机号怎么办国际用户输国家代码怎么办更麻烦的是业务侧还可能要求你把区号和号码分别存库如果只是做一个整体校验后续拆分还得再写一套逻辑。所以我在处理这类需求时会先把“校验”拆成几层来说第一层格式是否合法——即号码是否符合固定电话的基本结构。第二层业务约束是否通过——比如某些区号不在可呼叫范围内比如分机号位数上限。第三层输入规范化——把用户五花八门的输入空格、括号、横线转成统一的存储格式。这跟做密码校验是一个道理光判断“不为空”和判断“包含大小写字母加数字加特殊字符”完全是两个量级的需求。固定电话验证真正要做的是把“看起来像电话号”和“其实是可用电话号”区分开。1.2 固定电话的三段式结构固定电话和手机最大的区别在于它是“分层”的区号 本地号码 分机号。以中国大陆为例区号以0开头后面跟 3 或 4 位数字例如北京010、上海021、深圳0755、杭州0571。本地号码是 7 或 8 位数字例如12345678、8765432。分机号是拨打总机后继续拨的短号通常是 1 到 6 位数字例如801、1234输入时经常用-、#或中文“转”字连接。如果把这三段拆开看每一段的规则其实都不算复杂难的是如何组合成一个既严格又宽容的表达式。太严用户正常的输入格式会被误杀太宽随便一串数字也能过校验就失去了意义。1.3 明确适用场景别把需求做偏开始写代码之前我强烈建议先确认两件事这个输入框到底要不要接受手机号到底要不要接受国际号码我见过好几次因为需求没说清最后把固定电话规则写得跟手机万能正则一样结果验证形同虚设。固定电话验证的场景通常集中在这些地方企业联系资料录入需要存座机号码方便售后或客服外呼。用户收货信息有的用户就是不留手机只留座机系统需要能存能验。外呼系统白名单校验只允许添加格式正确的座机号码。如果只是做“看起来像座机号”的弱校验可以宽容一点如果要对接外呼线路或短信接口就必须严格按照运营商号段规则来。两者差异很大先确认再动手。2. 区号验证最容易被忽略的严格规则2.1 中国大陆区号的两种长度中国大陆固定电话区号分为 3 位和 4 位两类。3 位区号是各大中心城市包括010北京、021上海、022天津、023重庆、024沈阳、025南京、027武汉、028成都、029西安另外还有020广州。注意026这个号段并没有分配给任何城市早年有传闻说要给台北但实际通信规划中并未启用。4 位区号是 3 位区号以外的其他城市以03xx、04xx、05xx、06xx、07xx、08xx、09xx开头例如0311石家庄、0755深圳、0571杭州。比较坑的一点是如果只用^0\d{2,3}$来校验区号026这种不存在的区号也能通过。更严格的写法应该区分对待(?:010|02[0-9]|0[3-9]\d{2})这里用到了“或”分支010单独列出来02[0-9]匹配 021 到 029顺手排除了 026 这种不存在的号码0[3-9]\d{2}匹配 4 位区号里除 02 外的其他省份开头。这样写能排除大量无效区号并且不增加太多复杂度。2.2 国际区号国家代码要放在最前面如果你的系统面向的是有海外联系人的用户那么验证规则里还得考虑国家代码。国际区号国家代码长度从 1 位到 3 位不等例如美国1、俄罗斯7、英国44、中国86、新加坡65。最宽松的做法是接受或00开头的国家代码前缀(?:\?\d{1,3})?但要小心这个正则如果独立使用后面跟 0 到 3 位数字都能过‘86’可以‘1’可以但‘’单独出现也能过。所以实际使用时要配合后面的区号和号码部分保证国家代码后面必须跟着完整的本地号码。对于中国大陆业务更常见的选择是国家代码只允许86或0086或者完全不接受国家代码。这属于业务规则正则只负责搭建允许的框架。2.3 区号部分的容错写法括号和空格真实用户输入时区号常常被写成这些样子010-12345678(010) 1234567886 10 12345678从体验出发我倾向于让正则同时接受“带横线”“带空格”“带括号”的写法然后统一清洗成标准格式。一个比较顺手的区号正则片段是(?:(?:\?86[\s-]?)?(?:0\d{2,3})|(?:\(0\d{2,3}\)))[\s-]?这段代码允许010中国大陆常见写法0755-区号后带横线(010)括号包裹86 010国家代码 空格 区号86-21国家代码 横线 两位区号在正则里把可选的符号写成两到三种可能比只写死一种格式后续要处理的数据形态会舒服很多。3. 本地号码与分机号的验证细节3.1 本地号码的位数与开头限制本地号码是 7 或 8 位数字但不同城市长度有差异像北京、上海、广州这种大城市通常是 8 位本地号一些中小城市可能是 7 位。如果网络上传输或存储空间有限制可以让验证同时接受两种长度\d{7,8}有些技术方案会要求本地号码不能以0或1开头理由是这样能避免和特殊服务号码撞车。从严谨角度讲有点道理但实际中本地号码开头是 2 到 9 的占绝大多数真去严格限制开头反而容易误伤。我的做法是只限制“位数”不限制“开头数字”靠运营商侧去保证可用性。还有个隐藏细节本地号码可能出现“4 位区号 7 位本地号”和“3 位区号 8 位本地号”的常见组合但也存在“3 位区号 7 位本地号”的历史号码比如部分早期铺设线路的城市。所以不要写成“3 位区号必须配 8 位本地号4 位区号必须配 7 位本地号”那样会拦截掉不少真实可用的号码。3.2 分机号的常见写法分机号是整段验证里最容易因为格式问题被用户吐槽的。现实中分机号长这样-801#123转801空一格再写801写成12345没有分隔符我的推荐是接受“横线”和“#”作为分隔符分机号本身限制为 1 到 6 位数字(?:[-#]\d{1,6})?有人问为什么不支持中文“转”其实是支持的只是转义上比较麻烦。愿意做的话可以加一个(?:转\d{1,6})?。但从存储统一性来看我建议在提交时把“转”字符直接替换成-这样入库数据干净后续导出给外呼系统也方便。3.3 三段拼接完整正则示例把上面的片段拼到一起一个“看起来能打”的固定电话验证正则就出来了^(?:(?:\?86[\s-]?)?(?:0\d{2,3}|\(0\d{2,3}\))|(?:\?\d{1,3})?)[\s-]?\d{7,8}(?:[-#]?\d{1,6})?$解释一下各段(?:\?86[\s-]?)?可选的国家代码86或86后面可带空格或横线。(?:0\d{2,3}|\(0\d{2,3}\))区号允许带括号。[\s-]?区号和本地号之间的分隔符。\d{7,8}本地号码。(?:[-#]?\d{1,6})?可选的分机号。如果业务只针对中国大陆不想允许其他国家代码可以把最外层括号去掉直接写成^(?:\?86[\s-]?)?(?:0\d{2,3}|\(0\d{2,3}\))[\s-]?\d{7,8}(?:[-#]\d{1,6})?$注意分机号这里我把[-#]?改成了[-#]也就是要么不写分机要写就一定要带分隔符。否则“12345678”这种 8 位本地号后面再跟一堆数字容易把本地号和分机号混在一起不利于后面的拆分。4. 前端实操格式校验、自动清洗与号码拆分4.1 输入阶段先做“软校验”很多开发同学把校验逻辑全放在表单提交那一刻用户填错了再弹红字。这个流程体验不好更好的做法是“输入阶段 失焦阶段”双管齐下。输入阶段做两件事过滤非法字符、自动格式化。固定电话框里只允许数字、横线、空格、括号和#那么可以在oninput里直接把其他字符剔除掉input.addEventListener(input, function (e) { let val e.target.value; // 去掉所有非数字、非横线、非空格、非括号、非#的字符 val val.replace(/[^\d\s\-()#]/g, ); e.target.value val; });这能防止用户误输入字母或标点符号从源头减少脏数据。顺手还可以做长度限制比如总长不超过 20 位避免用户粘贴一长串无意义字符。4.2 失焦校验给用户明确的错误提示到失焦时再跑完整正则校验。这里我建议不要只写一个“电话格式不正确”而是分成三种提示区号缺了提示“请填写带区号的固定电话如 010-12345678”。本地号位数不对提示“本地号码通常为 7 到 8 位数字”。分机号格式不对提示“分机号请用-或#分隔如-801”。这样做的好处是用户能快速定位自己错在哪。有人觉得这功能麻烦但在用户资料表单里减少一次提交失败就是减少一次流失。4.3 把“验证”升级为“解析”校验通过后下一步是把用户输入的字符串拆解成区号、本地号、分机号三部分。这一步在做 CRM 导入、通讯录导出时会特别有用毕竟存一个phone字段是全串后续要按区号筛选客户就麻烦了。可以通过正则捕获组来做function parseFixedPhone(input) { const cleaned input.trim().replace(/[()]/g, ); const match cleaned.match(/^(?:\?86)?[\s-]?(0\d{2,3})[\s-]?(\d{7,8})(?:[-#](\d{1,6}))?$/); if (!match) return null; return { areaCode: match[1], // 含0的区号 localNumber: match[2], extension: match[3] || }; }这里我先把括号去掉了因为括号对数据的实际意义不大。然后通过正则捕获组把三段内容分别取出来。返回的对象可以直接用于入库、展示或后续拼接。剥离括号的操作不影响号码准确性但能让数据更规整。4.4 统一存储格式全数字还是带符号数据库里存固定电话我见过两种流派存全数字串例如01012345678。存格式化串例如010-12345678。如果业务侧有很多排序、筛选、去重需求全数字串是更优选择因为不带分隔符比较大小、匹配前缀都简单。如果业务需要“原样回显”那就存格式化串展示时不用再处理。更规范的做法是拆字段存储area_code、local_number、extension各存各的。这样最清晰也能避开“区号要不要带0”的争论——直接存规范化的010需要拼接时再自己拼。缺点是表结构稍微复杂查询时得拼起来再匹配。按我的经验如果这个号码是客户主联系方式拆字段存长期看很值。5. 常见问题与排查技巧实录5.1 400、800电话能不能用固定电话正则校验经常有业务把 400 电话也当成固定电话来录。400 电话的结构是400开头 7 位数字没有区号例如400-123-4567、4001234567。固定电话的区号规则要求以0开头400 不符合所以标准固定电话正则会把它拦掉。如果业务场景里有 400 电话要么单独加一个校验分支要么干脆在表单层面把“固话”和“400 热线”做成两个不同的输入项避免混在一起。我推荐后一种因为 400 号码没有区号和分机的概念硬塞进固定电话规则里会让逻辑变得很拧巴。5.2 用户粘贴进来的号码带一堆多余字符常见的脏数据样例和应对方式010 - 12345678横线前后有空格01012345678全角括号86-010-12345678国家代码和区号都带了001012345678-801区号、本地号、分机号之间没分隔符我的处理顺序是把全角字符转半角。去空格。再跑解析函数。全角转半角可以写个小工具函数把这些映射回 ASCII 对应的字符。如果你嫌麻烦也有现成 npm 包可用不过就一个几行函数的事我一般自己写。5.3 正则没问题但总有个别号码验证失败这种情况八成是“位数正确但区号规则兜不住”。比如 4 位区号的排列不止0[3-9]\d{2}这些实际上部分县区还使用 5 位区号的历史遗留号码在假号码测试时不会遇到但真用户提交时就会遇到。如果一个正则为了覆盖所有历史遗留号码被撑得特别复杂我建议折中主流程用严格正则校验不通过时再做一次宽松正则兜底只提示用户确认而不是直接拒绝。这在用户资料采集场景里体验尤为关键毕竟我们首要目标是不拦错人。5.4 一定要记得做长度上限约束固定电话虽然不会像手机号那样严格限制 11 位但正则一旦写成\d{7,8}如果前面国家代码和区号里还有86整串长度一般在 20 位以内。超过这个长度基本就是用户乱填了。我实际踩过一个坑某个用户从 Excel 里粘贴了一整行数据到一个输入框因为没做长度限制校验正则侥幸通过了一部分最后入到库里一堆残缺号码。后来我强制加了maxlength24并且在前端校验总长度这个问题瞬间消失。6. 最后再分享一些实操心得做固定电话验证这件事说难不难说简单也容易翻车。我现在每次接到这类需求都会先把问题抛回给产品这个号码之后要用来做什么是外呼、是展示、还是存档需求不同校验的严格程度就不同。如果是存档展示我把规则写得温和一点给用户提示而不是强硬拦截。如果是外呼系统那就必须严格按号码规则校验乱填一个根本打不通的号码浪费的是客服人员的时间。另外有一点我想特别提一下正则表达式虽然好用但不要指望一个正则包打天下。前端校验、后端校验、数据库约束三层各司其职前端负责体验后端负责数据安全数据库只负责格式兜底。把这三层都做扎实了固定电话验证这个看似简单的功能才真正耐打。
