似乎现在除了 10 ，11 ，12 都有号码段了

手机号要当做字符串来看待，不是数字

我一般都是直接 1 开头，11 位。。。。

直接 1 开头，11 位。。。。

请教一下，不涉及存储时，这一点的必要性是什么

🤔 当数字，起码他相信 JS 的数字精度。

130 ，131 ，132 ，133 ，134 ，135 ，136 ，137 ，138 ，139 ，141 ，145 ，146 ，147 ，148 ，149 ，150 ，151 ，152 ，153 ，155 ，156 ，157 ，158 ，159 ，165 ，166 ，167 ，170 ，171 ，172 ，173 ，174 ，175 ，176 ，177 ，178 ，180 ，181 ，182 ，183 ，184 ，185 ，186 ，187 ，188 ，189 ，191 ，198 ，199

＃4 可以用正则？

那 13666666666.6666666667 也是手机号

随便搜一个正则，也比用数字判断强，用数字判断手机号，都是野鸡手段

你不考虑 +86 156XXXXX 这种的么，15267116542.123456 也是手机号？

前端写正则，然后出了新号段，又是一个无法使用的 bug 。 这种问题我已经遇到 n 次了。 我一直搞不懂，为什么大家这么喜欢这么玩。

前端：手机号不验证，直接字符串

毕业就不写代码了，所以不会了，但是！我会百狗。。。 blog.csdn.net/itbrand/article/details/109239620

前端大哥们 别瞎判断了 早几年我换了个 166 的手机号 经常遇到手机号不正确的提示 不胜其烦

1 开头 11 为就可以了，现在还出了一些虚拟号段，按以前固定开头正则匹配太不灵活了

看情况吧，有些产品可能会限制虚拟号段，那就不能简单判断了

前端只需要做一些粗略的过滤就行，防止用户无意的错误提交就行，1 开头 11 位 是迟早的事，都是标准手机号

就简单的判断 1 开头 11 位吧，要不然都是在给自己挖坑，如果必须确认手机号可用就上短信验证码

我觉得贴小数的就是纯纯硬抬杠

特殊判断一般放接口，产品在后台配置

不接受国外手机号么？比如 gv

/^1[3456789]\d{9}$/其实排除掉 11 开头和 12 开头的就行了 嗯 还有 10 开头 其中的 6 7 9 什么的 也是后来慢慢加上的, 应该不会再加了吧

是 1 开头的 11 位纯数字字符串就可以了。 ^1\d{10}$没必要判断它是不是有效手机号，这个让业务层面去判断，比如短信验证码。

有开源的正则 github.com/VincentSit/ChinaMobilePhoneNumberRegex

别人的就一定对？还是 csdn 的...

＃4 130 亿 超过了 Java int 的范围

1 开头也是不太稳的，未来其实是规划 92 98 打头的

js 都是 number ，如果 JAVA 也肯定也是 Long 啊，不设计数据库存储的话，没感觉本质区别

前端验证了，后端照样验证
1 开头, 第二位不是 1 2, 后面 9 位全是数字就行...上面 21 楼都把正则贴出来了.

1 开头，后面十位数字就行了，别整那些花里胡哨的判断。对虚拟号段的用户很不友好

要是重要,就验证. 不重要的话爱写啥就写啥

纯纯懒狗

是你看错了，还是你 block 了太多人了，我这里看是 24 楼贴了 github 地址

多少还是正则验证下，前三位号段限制一下，工信部有公布,宽松点就前两位

直接 1 开头 11 位，鬼知道以后添加什么号段

现在正则也算复杂验证了吗？

＃28 超过 uint32 的数字不要用数值类型储存，每次让我使用 uint64 处理数字我都会 f**k 一下制定这个接口的人，在 32bit 系统上又耗性能又耗空间

重要的发短信验证码不重要的 1 开头

＃19 永远不要相信用户的输入

我提到好几次了，不涉及存储.....

第二位 0 漏掉了

＃4 不是数字的字符串，为什么要用数字表示呢。这个字符串的元素只是凑巧都是数字罢了，用数字表示有什么优势吗，没有，反而容易混淆试听。谁念手机号会一百五十亿 xxxx 的，都是一五零 xxx 的，这就是字符串。

起码现在还有 1%的服务无法识别 198 号段。

＃41 那你把我的“储存”理解为储存到变量，或者网络传输，程序计算，大概就这个意思，只要参与转换的场合 32bit 系统处理 uint64 都是很吃力的

原来前端还有人把手机号当数字使用...

不考虑其他国家的客户吗？区号不同，位数也不同啊

＃9 然后出个新号段正则匹配不上出事故是吧....

遇到过很多服务明明有用其他国家手机号注册的选项，但真的用海外号码时却会被前端挡住

前端必备技能，服的很

同一个号段指的是前四位一样，不是三位

JSON 传不了这么大的数字，你不涉及存储也不涉及传输？

想起来之前 QQ 号可以用 Hex 格式来登录的搞笑事情。。

我觉得没问题还很好，至少基本解决了手机号段更新导致 bug 的问题

这个问题，，，笑死~

+86 问题和电话号码中间有两个空格问题+86 111 1111 1111

给大家贡献一个梗，早些年在某家虚拟运营商实习的时候，一个充值页 webview ，前端正则判断没有纳入自家 170/171 ，然后出现了在自家 app 上面不能给自家手机号充值的故事。

判断长度即可，手机号的使用场景一般是接收验证码，输错了必然收不到，相当于二次校验，去判断手机号格式的纯粹是没事找事。

请前/后端别判断了, 用新号段手机号注册数字人民币账号提示手机号错误.

验证什么验证，直接发，能收到就成功，没收到就不成功。

直接不验证，谁输错谁负责

让后端校验

朋友说让短信网关验，返回啥你就返回过去，😄

讲究的就是一个物尽其用

＃48 出个新号段匹配不上也能算事故吗? 照这么说只要 1 开头+10 位数字 全放行得了. 还限制锤子.

我的美国号码 1530xxxxxxx

你问别人为什么要用字符串类型而不是数值类型，那你为什么要用数值类型呢？从类型的语义来讲，整数数值有两种含义，一是基数（ cardinal number ），表数量多少，二是序数（ ordinal number ），表有序实体在某种规则下的次序。手机号码很难直接对应到这两种含义中去。它只不过字符集恰好为十进制数字的字符串罢了。

/^1[3456789]\d{9}$/这个正则够用了/doge

我是会校验一下基本的，避免无意义的调接口，用的是'^(?:(?:\+|00)86)?1[1-9]\d{9}$'

吓人, 你们不调公安接口验证手机号是否真实有效的吗?

1 开头 11 位数字,足矣,别想着整那么多花里胡哨

把正则做成配置，读配置判断

啥接口？方便分享一下吗

＃64 如果新用户无法注册都不算事故, 那什么算事故啊. /^1[3456789]\d{9}$/ 这样就足够了, 跟你后面说的差不多, 没必要限制太多.

前端弄点宽松的限制就好

始终建议使用第三方库来判断手机号是否正确： github.com/google/libphonenumber考虑到电话号码的无处不在以及它们存在了多长时间，程序员继续对它们做出错误的假设令人惊讶。5. 电话号码不能重复使用？旧电话号码被回收并重新分配给其他人。7. 每个国家的呼叫代码恰好对应一个国家？美国、加拿大和几个加勒比岛屿共享国家呼叫代码+1 。16. 所有有效的电话号码都遵循国际电联的规范？ ITU-T 规定，电话号码不能超过十五位数字，为国家呼叫代码保留一到三位数字，但在德国分配了比这更长的有效号码。18. 电话号码只包含数字？在以色列，某些广告数字以开头。在新西兰，可以通过手机拨打555 来报告非紧急交通事故。Alpha 字符也可以用于电话号码中，例如 1-800-1-800-Flowers 。25. 电话号码就是数字？切勿尝试将电话号码存储为 int 或任何其他类型的数字数据类型。你不能对它们进行算术，虽然 007 、07 和 7 是相同的数字，但它们不一定是相同的电话号码——在一些国家，前导 0 是重要的，并构成数字本身的一部分。此外，电话号码可能包含其他可表示的字符或分机号部分，在等待提示音后拨打。提示：使用库来解析和格式化数字，以正确处理每个国家的数据。26. 政府或电信公司发布的电话号码计划代表了现实？国家编号计划，如国际电联管理的计划，代表了政府或电信的意图。这些可以在现实世界中实际实施编号计划更改之前、期间或之后发布。电话号码范围生效的实际日期可能并不总是符合官方公告。

一旦出现 9 开头手机号你又该怎么处理 233

/^(?:(?:+|00)86)?1[3-9]\d{9}$/

/^1[\d]{10}$/

你这杠出花来了

向你道歉，是我单纯了。。。对不起老哥

是有多蠢比较数值

哈哈哈，这也太好玩了吧，手机号应该是字符串啊

如果以后有 2 开头的手机号了怎么办

0120-993-993这是苹果日本官网的电话，0 开头，分号隔断，阁下如何应对？ PS：这里面还没国家区号咧，加上区号就是 +81 0120-993-993 或者 081 0120-993-993

空格或者小数点分隔的手机号怎么办呢，比如123 4567 890112 345 678 901123.456.78.901

前端简单判断下 1 开头 11 位就可以,如果想要更准确判断,对于某些校验可能会有改动的可以放到后端使用字典配置个正则表达式缓存起来使用

/t/977026刚刚看到这个，以后说不定要有 9 开头的了

根本就没必要判断！只会给使用特殊号码的人带来麻烦！遇到过很多这种完全多余的限制了！少写点 BUG 不好吗！！！