拜托前端同学们不要再用正则验证手机号了

[leafiy]

说一个自己的经历，2017 年末 166 放号的第 6 个月，刚坐完 11 小时航班的我一路没睡，临晨 4 点孤独的拿着 166 手机号站在首都机场登录不上任何一个打车 APP。而出租车排队了 10000 个人。

今天从美帝回来的同事又遇到了同样问题，198 也放号快 1 年了吧，各个大厂的微信端、小程序都没更新正则，老外不会下 app，还好我远程帮忙叫了首汽约车和外卖。

付解决方案：

1.国内产品，简单粗暴，1+10d，剩下交给服务商

2.国际产品带国家前缀的： https://github.com/google/libphonenumber

我错了，标题中「前端」应修改为「前后端 UI 产品老板测试财务黑白黄 LGBT 」

这个问题不是前端的锅，也不是产品的锅，是我的锅。发帖的时候刚刚帮老外叫完车，怒火中烧，没想到这么基础的问题过了好多年还是会发生在大厂身上。（尤其是病入膏肓的滴滴，让我火上加火，滴滴的产品全抓起来先崩后问没有冤假错案。不仅手机号一例，不展开说了）

滴滴美团饿了么京东百度甚至老外的 airbnb uber 的前端产品无一幸免，转产品之前也在前面一家企业做了 5 年的前端，经验告诉我，这确实是我的锅，我从来没有接到过类似于「用正则限制手机号段」的需求，而都是「限制用户只能提交手机号」这种需求，如果我犯懒了，问题就来了。

有人提到这里测试应该发挥作用了，这种基础问题和未来有可能的变动交给测试同学，抱歉这个世界还没那么理想化，至少我工作过的大厂无论是 prd 还是测试还是产品还是线上测试志愿者，在当年都没能预知这个问题，而我司的工作流程已经在业内颇受好评。

感谢各位开发大大喷我，但是产品出现这种问题，我不认为开发可以 100%撇清责任，在开发阶段多思考一下需求，共同让产品往好的方向发展不是作为公司成员最基础的职能之一吗？最后希望大家都不做产品 IDE

还有，我依然很好奇那位朋友是如何将「向产品提出合理的基础性问题」演变为「后端没设计好你咋不和他据理力争？ 产品设计的不好你咋不和他据理力争？ UI 画的不漂亮你咋不反应一下？ 」这种问题的，如果我能获取这种能力，应该快可以买房了。

[dd0754]

我都是 1 加 10 个数字。。。

[lagoon]

这你得和产品说

[leafiy]

@dd0754 这才是正解

[leafiy]

@lagoon 产品管正则的？这么宽？

[aimaodeyuer]

1 开头加 10 个数字最保险，按照号段你这样的就完了。

[zqx]

我从不建议在前端做任何多余的校验。前端应该考虑的是体验，过度的安全设计牺牲了体验，导致用户流失，得不偿失。

[Mohanson]

京东也是这种傻逼设定，填新号就说你输入错误的手机号码。去年是这样，今年不知道。

[imherer]

想起之前买了个 173 的号码，想充点话费……试了好多个 app 都说手机号码有误……

[EastLord]

我也是 166 的号，偶尔会遇到问题 "提示请输入正确的手机号"

[ffeii]

https://github.com/google/libphonenumber

[0987363]

用正则才不会出现这种问题，这种多半是产品要求按照号段进行严格限制

[buried]

我 14 年 178 的手机号，自己公司的 app 正则 18 年还没更新……

[lzxgh621]

这事跟技术无关，我就不信他们没有接到投诉，多半是不想通过。

[leafiy]

@lzxgh621 2018 年初，我在 v2 就这个问题 @了 N 个滴滴的 v 友，后来有个号称 PM 的致电我，花了半小时时间，宁可说服是我不会操作，也不可肯自己试一下滴滴小程序和公众号，从此就远离一切滴滴系产品了。

后来经测试，直到 2019 年 1 月，滴滴系产品的公众号和小程序才更新了新手机号段支持

[leafiy]

@0987363 我描述不严谨，不要用正则验证号段了。。

[VoidChen]

@lzxgh621 你怎么知道投诉他们会看= =

[yhxx]

1. 不一定是前端校验的
2. 很多时候这是产品的需求

[lagoon]

@leafiy 你写的宽泛了，产品说不行。咋办呢？

[iNaru]

先试试绕过前端构造请求看是否只有前端限制吧，说不定后端同样限制呢？

[Jirajine]

很多程序员真是啥都甩锅产品，搞得自己好像就是个产品手里的 IDE，并且不承担任何责任。

[leafiy]

@yhxx okok

开发：这是产品定的
产品：这是开发写的

所以问题不存在。

[leafiy]

@lagoon 产品说限制号段，开发连一句反问「工信部新发号段怎么办」的权利都没有？

[dobelee]

稍微大点的公司都是产品的需求。

[leafiy]

@dobelee 再复制一遍咯

产品说限制号段，开发连一句反问「工信部新发号段怎么办」的权利都没有？

[leafiy]

@iNaru 反正后端有限制，前端同学不需要注意啦。这难道不是一个有则改之无则加勉的问题吗？

[ScepterZ]

就算要严格限制，也不该好几个月还不更新

[Caballarii]

会不会因为短信供应商不支持导致的？供应商不支持的话 1 加 10 也没用。。。

[dobelee]

@leafiy sorry。有时候还真没有。

[Exia]

看来解决办法只能是大家都及时更新判断的关键字吧？

[leafiy]

@dobelee 这是公司还是朝廷，pm 是大大吗？用户都有反馈渠道，自己公司人员不能反问？这是什么产品哦

[lagoon]

@leafiy 你可以说啊，不代表人家就会觉得你说的对。。。。咋的？你打算和产品打一架？

[lagoon]

@leafiy 退一步说，加不加影响前端使用？是页面变形？还是跳转出 bug ？都不是吧？你怎么就觉得这是前端主动要求，非要往上加。。。

[leafiy]

@lagoon 「工信部新发号段怎么办」如果连这种问题 pm 都说不对，不打他丫的留着干嘛？

[lagoon]

@leafiy 我见过的码农地位普遍不如产品。除非是很难的事情，不然哪个码农没事和产品吵。吵上 2 天，产品很淡定，码农一行代码没写。

[lagoon]

@leafiy 好，和他打一天。产品说你说的很多，按你说的做吧。你一行代码没写，领导说你咋没写完呢？然后再把领导打一架？你牛。我服气。见谁揍谁，公司自己最大。你这么牛，肯定是知乎来的年薪千万的老总吧。

[robinlovemaggie]

@aimaodeyuer
复议，国内的手机号我只用：/^1\d{10}$/

[lagoon]

@leafiy 火气咋这么大呢？产品设计的不好，就全是前端的责任？
说句产品负责还发飙了？
退一步说，码农只管开发，测试怎么测的，产品怎么验收的？验收完之后出现问题你说全是码农的错？

[leafiy]

@lagoon 我是个鶸🐔产品，但是如果我的开发提出类似于「工信部新发号段怎么办」这种我没有考虑到但以后可能发生状况，我肯定会重新考虑需求而不是被开发暴打。
万事没有绝对，我说的问题前提是提出一个合理疑问，被你理解为「处理合理疑问」也需要比比谁的地位高，谁的脾气大，那我觉得你很牛，年薪应该是我的千倍开外。

[bojackhorseman]

@lagoon #34 很真实，以前跟 pm 讨论半天问题，结果找到了解决方案，还是得自己乖乖敲代码。

[lagoon]

@leafiy 按你的逻辑，一切都是前端的问题。
后端没设计好你咋不和他据理力争？
产品设计的不好你咋不和他据理力争？
UI 画的不漂亮你咋不反应一下？
公司运营方向不对，开发连一句反问的权利都没有？

[lagoon]

@leafiy 怪不得了。原来是产品。。。。
我就说嘛。。。
实际体验，产品回答：以后出现，以后再说。

[lagoon]

@bojackhorseman 这是前辈的经验，都是泪。
许多公司，上线时间是定死的。
和产品讨论的越多，产品设计越完善，开发时间越少。
不是不讨论，前提是要有讨论的环境

[luoway]

如果是前端校验，正则不会出号段问题。
只可能是前端比较数字大小，或者后端校验。

[iNaru]

@leafiy 这显然是前后端验证一致性问题。希望不要到时又要骂前端：什么破前端，明明显示验证无错误，为什么提交又失败。

[leafiy]

@lagoon 谁在放大一个小小的合理疑问？万事都不是绝对，任何一个产品都做不到产品设计顾及到以后可能发生的意外情况，开发在写代码过程中遇到了产品没处理好的情况，非常常见，如果遇到意外，去提出疑问，到你嘴里变成了「一切都是前端 xx 」「和 xxxx 据理力争」「地位高低 xxxx 」？

[leafiy]

@iNaru 我不相信有合格的产品 er 会提「这里用正则表达式限制用户输入手机号」的需求，而是「如果这里用户输入的不是手机号」，这个情况下开发是应该发挥一点能动性坐成新号段友好的，还是随便找个手机号正则去做呢？

前面补充了，这是一个有则改之无则加勉的问题

[liyuhang]

这就是做事情只考虑现在不考虑未来的情况

[warcraft1236]

我记得 Google 有一个库就是校验手机号的，用这种公共的不好吗？

[iNaru]

@leafiy 要是后端同样限制，前端单方面加勉个鬼？

[leafiy]

@iNaru 了解了，因为后端也「有可能」有限制，所以前端不需要注意此问题了

[lululau]

所以到底为什么要验证手机号格式呢

[iNaru]

@leafiy 是的，所以我一开始就委婉地说明了，先确定是否是"只是"前端的问题，才开骂好吗？

[yamedie]

10，11，12 开头的除外。（见过哪个手机号 110 开头的务必告诉我一下

[leafiy]

@warcraft1236 之前过面试一个前端大牛，原话我觉得非常有道理

「 XX 库哪有 13d{8}来的爽，IDE 开发者只能叫码农当螺丝钉」

[CFO]

还不是傻逼测试提的问题

[leafiy]

@lululau 1L 已给出正解，剩下的交给短信服务商

[lululau]

@leafiy 手机号一定会是 11 位，并且第一位永远都是 1 ？宪法规定的？

[skiy]

号段已经发完啦。所以这个只能算伪命题了。12/11 不可能还当手机号吧

[SEARCHINGFREE]

就是就是，你们前端怎么没有预知未来的能力呢，像我们产品文档啥都不明确怎么可能出这种错呢。🐶

[leafiy]

@skiy 5 开头和 12 位已进入研讨阶段了，还有在大陆的老外们

[leafiy]

@SEARCHINGFREE nice

[xiyiailoli]

我都是保证 11 个数字就完了

[wu67]

/^1[3-9]\d{9}$/ 反正我是这样写的. 垃圾的不是前端而是人. 还有上面各种撕的真是搞不懂脑回路…

[CSwater]

从来只保证位数，转手丢给后端去校验。谁有想法都被我强行按下去了(狗头

[otakustay]

@lagoon 无论你是产品、前端、后端、运维、测试，提出对产品更好的观点并坚持下去不是很基础的做法吗……

[fengbjhqs]

大佬，后端也可能会验证的， 只是你遇到的是前端验证， 这个锅前端不能完全背

[leavebody]

199 开头的不能同意更多

[CloudnuY]

连 12321 举报中心都不能举报 166 号段的垃圾短信……

[skiy]

@leafiy 12 位的话，估计全得改。15x 早就有了。5x ？这种跟本地固话乱了。不过，我之前以为 95599 之类的只有 5 位特服号，后来才发现，居然还有 966966 之类的 6 位数。这样子的话，得运营商靠停顿时间来校验被叫号码了。。。在大陆的老外们，这个确实不友好，但是大部分短信平台都没有外发国际号码短信的吧。这个得对接国际短信平台了。

[vincentxue]

顺势无耻地插一则广告。
https://github.com/VincentSit/ChinaMobilePhoneNumberRegex

[lzxgh621]

@skiy #69 还有六位扩充八位的骚操作 9525 的垃圾电话就是这么来的

[stone666]

[1][0-9]{10}

[mooczz]

这又不是正则的锅，这是产品设计的锅

[leafiy]

@mooczz nice

[billlee]

我是开发。类似这种明显有问题还要增加工作量的需求我一般都是直接怼回去的。

[watzds]

做这种检验就是产品多管闲事，以为限制越多越好

[em2046]

最近的新项目产品要求手机号码是 18 位以下数字和'-'字符
感觉可以很久不需要维护
比较宽松了，毕竟收不到验证码是自己输入的问题

[Steps]

@robinlovemaggie #36 /^1[3-9]\d{9}$/

我用这个。。。

[welling]

表示说不过产品，他的职责是和你谈，你的职责是写代码，若是样样都要辩个你死我活，亏的肯定是你。因为谈完，他的事就完了，你呢，代码写完没。
我是 5 分钟说不定就直接做，除非真的很难，或者很沙比的需求，让他提需求单，并把链接写到代码里，出问题，就贴证据甩锅呗

[starsriver]

还有就是，说不定不是前端的锅，是服务器的判断结果呢

[jason19659]

@dd0754 #1 现在这样我都不敢。。直接\d+然后验证交给短信验证码来做。。

[kopisee]

^1(3(([0-3]|[5-9])\d{8}|4[0-8]\d{7})|4(5|7|9)\d{8}|5([0-3]|[5-9])\d{8}|6(6|7)\d{8}|7([0-3]|[5-8])\d{8}|8\d{9}|9(1|8|9)\d{8})$

[weixiangzhe]

事实上 之后会有 92 开头的 ，你们可以查下工信部的

[cheakyam]

我觉得最好的方案应该是工信部提供一个号段查询接口，想做校验的定期调用这个接口更新自己的规则就好了。

[szdubinbin]

1，有些朋友说产品没管这么多的，那就是产品失误或者脱裤子放屁谢谢，严谨的产品流程，PRD 上甚至会规定好字段名和很多未知情况的预案(来自 bat 某家和头条系朋友的告知)
2，开发(这里泛指整条开发链路，包括测试)如果真的发现 PRD 或者实际开发有沙雕明显问题一个屁都不放就给上线，那我真的不知道怎么评价这个事情。
当然那种产品文档一堆逻辑漏洞，需要开发 2，3 天上线的不在此列 （狗头）

[zzlove]

拜托产品和测试同学不要啥事儿都甩锅给前端，最起码先确认一下

[leafiy]

@zzlove nice

[galaxyyao]

因为自己是产品经理，说话时屁股就歪成这样子。。。
从我在两家公司遇到的情况来说，都是产品提的这个需求。不是产品文档上写着号码段，哪个开发不愿意只校验个长度？闲得蛋疼为了这事补单元测试？受苦的是写用例的测试，以及为了产品轻飘飘一句“那就放开呗”紧急发版本上线的开发运维。
就算开发真的没提醒一句，主要责任也是出出需求的产品。现在的产品闯红灯被车撞都要怪旁边人没拉一把了么？

[galaxyyao]

作为一个团队，出了这种 bug 都有责任，不管是开发测试还是项目经理。除了运维，谁也不可能把自己完全撇清责任。
再重复一遍，开发产品测试项目经理都有责仁。
但责任也分主次。如果这种需求设计纰漏的主要责任人甩给开发，就等同于将代码逻辑 bug 的主要责任人甩给产品一样可笑。
遇到这类问题会发火也是人之常情，但一般都是骂：“现在也是什么 s [哔] 也能当产品经理了。前端看到这种需求请往死里怼”。不骂产品反而骂开发，只会让人觉得：“不愧是产品，甩锅技术一流”

[alphatoad]

只允许国内身份证和国内手机号注册的服务都是屑。
只支持微信支付和支付宝的服务都是屑。
每次回国跟打仗一样，斗智斗勇

[greatghoul]

说实话，前端不背这个锅。

[xiaolanger]

一个产品，吐槽的时候，都分不清前后端的责任，这算是直接暴露了产品的本质吗？

[zxcslove]

@leafiy 这公司病得不轻

[sugars]

前端同学有苦说不出呀，不背锅，反正我的手机正则支持 166
/^(13[0-9]|14[579]|15[0-3,5-9]|16[6]|17[0135678]|18[0-9]|19[89])\d{8}$/

[l00t]

连拒需求都不会？这开发当得也太怂了。

[sarices]

后端也要验证啊，你要不要跟后端说说？

[encro]

10000000000<n>19999999999

[jzmws]

我之前的一个项目 ，手机号校验过不去 ，后面改成直接 1 开头的十一位

[yhxx]

原来楼主是产品，那就能理解了。。。

正常情况下哪个开发会愿意写这么复杂的校验需求，还要区分 18xxxxx 可以，16xxxxx 不行

直接校验 11 位数字一把梭多简单粗暴

这种东西大部分情况下都是产品严格要求才会做的吧？

稍有质疑就是“用户体验“

然后回到主楼的问题，新上线的产品一般不会有这种问题吧？

至于旧的，还不是你们当年要求这么做的？

[FaiChou]

网上随便找一个排名靠前的手机号正则, 用自己的手机号测试通过, mock 几个手机号测试也通过, 上线发版.

Test code in production.

于是发现部分号段手机号主人反馈不能发送验证码, 经调查, 网上正则是 10 年前过时的答案, 于是连带着测试扣绩效吧..