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

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

^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})$

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

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

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

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

@zzlove nice

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

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

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

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

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

@leafiy 这公司病得不轻

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

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

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

10000000000<n>19999999999

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

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

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

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

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

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

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

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

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

Test code in production.

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