这是一个创建于 2293 天前的主题，其中的信息可能已经有所发展或是发生改变。
说一个自己的经历，2017 年末 166 放号的第 6 个月，刚坐完 11 小时航班的我一路没睡，临晨 4 点孤独的拿着 166 手机号站在首都机场登录不上任何一个打车 APP。而出租车排队了 10000 个人。
今天从美帝回来的同事又遇到了同样问题，198 也放号快 1 年了吧，各个大厂的微信端、小程序都没更新正则，老外不会下 app，还好我远程帮忙叫了首汽约车和外卖。
第 1 条附言 2019-07-11 18:28:37 +08:00
第 2 条附言 2019-07-11 19:02:12 +08:00
我错了，标题中「前端」应修改为「前后端 UI 产品老板测试财务黑白黄 LGBT 」
第 3 条附言 2019-07-12 12:56:46 +08:00
这个问题不是前端的锅，也不是产品的锅，是我的锅。发帖的时候刚刚帮老外叫完车，怒火中烧，没想到这么基础的问题过了好多年还是会发生在大厂身上。（尤其是病入膏肓的滴滴，让我火上加火，滴滴的产品全抓起来先崩后问没有冤假错案。不仅手机号一例，不展开说了）
滴滴美团饿了么京东百度甚至老外的 airbnb uber 的前端产品无一幸免，转产品之前也在前面一家企业做了 5 年的前端，经验告诉我，这确实是我的锅，我从来没有接到过类似于「用正则限制手机号段」的需求，而都是「限制用户只能提交手机号」这种需求，如果我犯懒了，问题就来了。
有人提到这里测试应该发挥作用了，这种基础问题和未来有可能的变动交给测试同学，抱歉这个世界还没那么理想化，至少我工作过的大厂无论是 prd 还是测试还是产品还是线上测试志愿者，在当年都没能预知这个问题，而我司的工作流程已经在业内颇受好评。
感谢各位开发大大喷我，但是产品出现这种问题，我不认为开发可以 100%撇清责任，在开发阶段多思考一下需求，共同让产品往好的方向发展不是作为公司成员最基础的职能之一吗？最后希望大家都不做产品 IDE
还有，我依然很好奇那位朋友是如何将「向产品提出合理的基础性问题」演变为「后端没设计好你咋不和他据理力争？ 产品设计的不好你咋不和他据理力争？ UI 画的不漂亮你咋不反应一下？ 」这种问题的，如果我能获取这种能力，应该快可以买房了。
滴滴美团饿了么京东百度甚至老外的 airbnb uber 的前端产品无一幸免，转产品之前也在前面一家企业做了 5 年的前端，经验告诉我，这确实是我的锅，我从来没有接到过类似于「用正则限制手机号段」的需求，而都是「限制用户只能提交手机号」这种需求，如果我犯懒了，问题就来了。
有人提到这里测试应该发挥作用了，这种基础问题和未来有可能的变动交给测试同学，抱歉这个世界还没那么理想化，至少我工作过的大厂无论是 prd 还是测试还是产品还是线上测试志愿者，在当年都没能预知这个问题，而我司的工作流程已经在业内颇受好评。
感谢各位开发大大喷我，但是产品出现这种问题，我不认为开发可以 100%撇清责任，在开发阶段多思考一下需求，共同让产品往好的方向发展不是作为公司成员最基础的职能之一吗？最后希望大家都不做产品 IDE
还有，我依然很好奇那位朋友是如何将「向产品提出合理的基础性问题」演变为「后端没设计好你咋不和他据理力争？ 产品设计的不好你咋不和他据理力争？ UI 画的不漂亮你咋不反应一下？ 」这种问题的，如果我能获取这种能力，应该快可以买房了。
 | 1 dd0754 2019-07-11 16:34:49 +08:00 via iPhone 我都是 1 加 10 个数字。。。 |
 | 2 lagoon 2019-07-11 16:36:35 +08:00 这你得和产品说 |
5 aimaodeyuer 2019-07-11 16:40:48 +08:00 1 开头加 10 个数字最保险，按照号段你这样的就完了。 |
 | 6 zqx 2019-07-11 16:42:26 +08:00 via Android 我从不建议在前端做任何多余的校验。前端应该考虑的是体验，过度的安全设计牺牲了体验，导致用户流失，得不偿失。 |
 | 7 Mohanson 2019-07-11 16:42:54 +08:00 via Android 京东也是这种傻逼设定，填新号就说你输入错误的手机号码。去年是这样，今年不知道。 |
 | 8 imherer 2019-07-11 16:43:02 +08:00 想起之前买了个 173 的号码，想充点话费……试了好多个 app 都说手机号码有误…… |
 | 9 EastLord 2019-07-11 16:44:44 +08:00 我也是 166 的号，偶尔会遇到问题 "提示请输入正确的手机号" |
 | 10 ffeii 2019-07-11 16:44:57 +08:00  3 |
 | 11 0987363 2019-07-11 16:45:39 +08:00 via Android 3 用正则才不会出现这种问题，这种多半是产品要求按照号段进行严格限制 |
 | 12 buried 2019-07-11 16:47:06 +08:00 我 14 年 178 的手机号，自己公司的 app 正则 18 年还没更新…… |
 | 13 lzxgh621 2019-07-11 16:49:46 +08:00 via iPhone 这事跟技术无关，我就不信他们没有接到投诉，多半是不想通过。 |
 | 14 leafiy OP 1 @lzxgh621 2018 年初，我在 v2 就这个问题 @了 N 个滴滴的 v 友，后来有个号称 PM 的致电我，花了半小时时间，宁可说服是我不会操作，也不可肯自己试一下滴滴小程序和公众号，从此就远离一切滴滴系产品了。 后来经测试，直到 2019 年 1 月，滴滴系产品的公众号和小程序才更新了新手机号段支持 |
 | 17 yhxx 2019-07-11 17:13:13 +08:00 1. 不一定是前端校验的 2. 很多时候这是产品的需求 |
 | 19 iNaru 2019-07-11 17:18:32 +08:00 先试试绕过前端构造请求看是否只有前端限制吧，说不定后端同样限制呢？ |
 | 20 Jirajine 2019-07-11 17:19:52 +08:00 via Android 7 很多程序员真是啥都甩锅产品，搞得自己好像就是个产品手里的 IDE，并且不承担任何责任。 |
 | 23 dobelee 2019-07-11 17:22:42 +08:00 via Android 稍微大点的公司都是产品的需求。 |
 | 26 ScepterZ 2019-07-11 17:25:42 +08:00 就算要严格限制，也不该好几个月还不更新 |
 | 27 Caballarii 2019-07-11 17:27:17 +08:00 会不会因为短信供应商不支持导致的？供应商不支持的话 1 加 10 也没用。。。 |
 | 29 Exia 2019-07-11 17:29:38 +08:00 看来解决办法只能是大家都及时更新判断的关键字吧？ |
| 32 lagoon 2019-07-11 17:35:33 +08:00 @leafiy 退一步说，加不加影响前端使用？是页面变形？还是跳转出 bug ？都不是吧？你怎么就觉得这是前端主动要求，非要往上加。。。 |
| 34 lagoon 2019-07-11 17:37:30 +08:00 @leafiy 我见过的码农地位普遍不如产品。除非是很难的事情，不然哪个码农没事和产品吵。吵上 2 天，产品很淡定，码农一行代码没写。 |
| 35 lagoon 2019-07-11 17:39:12 +08:00 1 @leafiy 好，和他打一天。产品说你说的很多，按你说的做吧。你一行代码没写，领导说你咋没写完呢？然后再把领导打一架？你牛。我服气。见谁揍谁，公司自己最大。你这么牛，肯定是知乎来的年薪千万的老总吧。 |
 | 36 robinlovemaggie 2019-07-11 17:41:43 +08:00 1 @aimaodeyuer 复议，国内的手机号我只用：/^1\d{10}$/ |
| 37 lagoon 2019-07-11 17:42:18 +08:00 |
| 38 leafiy OP @lagoon 我是个产品，但是如果我的开发提出类似于「工信部新发号段怎么办」这种我没有考虑到但以后可能发生状况，我肯定会重新考虑需求而不是被开发暴打。 万事没有绝对，我说的问题前提是提出一个合理疑问，被你理解为「处理合理疑问」也需要比比谁的地位高，谁的脾气大，那我觉得你很牛，年薪应该是我的千倍开外。 |
| 40 lagoon 2019-07-11 17:45:52 +08:00 2 @leafiy 按你的逻辑，一切都是前端的问题。 后端没设计好你咋不和他据理力争？ 产品设计的不好你咋不和他据理力争？ UI 画的不漂亮你咋不反应一下？ 公司运营方向不对，开发连一句反问的权利都没有？ |
| 42 lagoon 2019-07-11 17:47:47 +08:00 2 |
 | 43 luoway 2019-07-11 17:53:19 +08:00 如果是前端校验，正则不会出号段问题。 只可能是前端比较数字大小，或者后端校验。 |
| 45 leafiy OP @lagoon 谁在放大一个小小的合理疑问？万事都不是绝对，任何一个产品都做不到产品设计顾及到以后可能发生的意外情况，开发在写代码过程中遇到了产品没处理好的情况，非常常见，如果遇到意外，去提出疑问，到你嘴里变成了「一切都是前端 xx 」「和 xxxx 据理力争」「地位高低 xxxx 」？ |
| 46 leafiy OP @iNaru 我不相信有合格的产品 er 会提「这里用正则表达式限制用户输入手机号」的需求，而是「如果这里用户输入的不是手机号」，这个情况下开发是应该发挥一点能动性坐成新号段友好的，还是随便找个手机号正则去做呢？ 前面补充了，这是一个有则改之无则加勉的问题 |
 | 47 liyuhang 2019-07-11 18:06:47 +08:00 这就是做事情只考虑现在不考虑未来的情况 |
 | 48 warcraft1236 2019-07-11 18:11:38 +08:00 我记得 Googl 有一个库就是校验手机号的，用这种公共的不好吗？ |
 | 51 lululau 2019-07-11 18:19:43 +08:00 所以到底为什么要验证手机号格式呢 |
 | 53 yamedie 2019-07-11 18:21:05 +08:00 via Android 10，11，12 开头的除外。（见过哪个手机号 110 开头的务必告诉我一下 |
| 54 leafiy OP |
 | 55 CFO 2019-07-11 18:23:59 +08:00 via Android 还不是傻逼测试提的问题 |
 | 58 skiy 2019-07-11 18:29:08 +08:00 via Android 号段已经发完啦。所以这个只能算伪命题了。12/11 不可能还当手机号吧 |
 | 59 SEARCHINGFREE 2019-07-11 18:29:49 +08:00 via iPhone 就是就是，你们前端怎么没有预知未来的能力呢，像我们产品文档啥都不明确怎么可能出这种错呢。 |
| 61 leafiy OP @SEARCHINGFREE nice |
 | 62 xiyiailoli 2019-07-11 18:43:56 +08:00 via Android 我都是保证 11 个数字就完了 |
 | 63 wu67 2019-07-11 18:44:13 +08:00 1 /^1[3-9]\d{9}$/ 反正我是这样写的. 垃圾的不是前端而是人. 还有上面各种撕的真是搞不懂脑回路… |
 | 64 CSwater 2019-07-11 18:53:12 +08:00 via iPhone 从来只保证位数，转手丢给后端去校验。谁有想法都被我强行按下去了(狗头 |
 | 66 fengbjhqs 2019-07-11 18:58:14 +08:00 大佬，后端也可能会验证的， 只是你遇到的是前端验证， 这个锅前端不能完全背 |
 | 67 leavebody 2019-07-11 19:42:49 +08:00 199 开头的不能同意更多 |
 | 68 CloudnuY 2019-07-11 19:48:10 +08:00 连 12321 举报中心都不能举报 166 号段的垃圾短信…… |
| 69 skiy 2019-07-11 20:10:57 +08:00 via Android @leafiy 12 位的话，估计全得改。15x 早就有了。5x ？这种跟本地固话乱了。不过，我之前以为 95599 之类的只有 5 位特服号，后来才发现，居然还有 966966 之类的 6 位数。这样子的话，得运营商靠停顿时间来校验被叫号码了。。。在大陆的老外们，这个确实不友好，但是大部分短信平台都没有外发国际号码短信的吧。这个得对接国际短信平台了。 |
 | 70 vincentxue 2019-07-11 20:13:12 +08:00 2 |
 | 72 stone666 2019-07-11 20:31:17 +08:00 [1][0-9]{10} |
 | 73 mooczz 2019-07-11 21:39:38 +08:00 via iPhone 这又不是正则的锅，这是产品设计的锅 |
 | 75 billlee 2019-07-11 22:04:36 +08:00 我是开发。类似这种明显有问题还要增加工作量的需求我一般都是直接怼回去的。 |
 | 76 watzds 2019-07-11 22:38:05 +08:00 via Android 做这种检验就是产品多管闲事，以为限制越多越好 |
 | 77 em2046 2019-07-11 23:05:28 +08:00 最近的新项目产品要求手机号码是 18 位以下数字和'-'字符 感觉可以很久不需要维护 比较宽松了，毕竟收不到验证码是自己输入的问题 |
 | 78 Steps 2019-07-11 23:08:40 +08:00 |
 | 79 welling 2019-07-11 23:23:18 +08:00 via Android 1 表示说不过产品，他的职责是和你谈，你的职责是写代码，若是样样都要辩个你死我活，亏的肯定是你。因为谈完，他的事就完了，你呢，代码写完没。 我是 5 分钟说不定就直接做，除非真的很难，或者很沙比的需求，让他提需求单，并把链接写到代码里，出问题，就贴证据甩锅呗 |
 | 80 starsriver 2019-07-11 23:44:29 +08:00 via Android 还有就是，说不定不是前端的锅，是服务器的判断结果呢 |
 | 81 jason19659 2019-07-11 23:53:01 +08:00 @dd0754 #1 现在这样我都不敢。。直接\d+然后验证交给短信验证码来做。。 |
 | 82 kopisee 2019-07-12 00:28:28 +08:00 via Android ^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})$ |
 | 83 weixiangzhe 2019-07-12 00:43:30 +08:00 via iPhone 1 事实上 之后会有 92 开头的 ，你们可以查下工信部的 |
 | 84 cheakyam 2019-07-12 00:53:58 +08:00 我觉得最好的方案应该是工信部提供一个号段查询接口，想做校验的定期调用这个接口更新自己的规则就好了。 |
 | 85 szdubinbin 2019-07-12 00:57:39 +08:00 1，有些朋友说产品没管这么多的，那就是产品失误或者脱裤子放屁谢谢，严谨的产品流程，PRD 上甚至会规定好字段名和很多未知情况的预案(来自 bat 某家和头条系朋友的告知) 2，开发(这里泛指整条开发链路，包括测试)如果真的发现 PRD 或者实际开发有沙雕明显问题一个屁都不放就给上线，那我真的不知道怎么评价这个事情。 当然那种产品文档一堆逻辑漏洞，需要开发 2，3 天上线的不在此列 （狗头） |
 | 86 zzlove 2019-07-12 03:32:42 +08:00 拜托产品和测试同学不要啥事儿都甩锅给前端，最起码先确认一下 |
 | 88 galaxyyao 2019-07-12 05:12:04 +08:00 via iPhone 2 因为自己是产品经理，说话时屁股就歪成这样子。。。 从我在两家公司遇到的情况来说，都是产品提的这个需求。不是产品文档上写着号码段，哪个开发不愿意只校验个长度？闲得蛋疼为了这事补单元测试？受苦的是写用例的测试，以及为了产品轻飘飘一句“那就放开呗”紧急发版本上线的开发运维。 就算开发真的没提醒一句，主要责任也是出出需求的产品。现在的产品闯红灯被车撞都要怪旁边人没拉一把了么？ |
| 89 galaxyyao 2019-07-12 05:59:50 +08:00 via iPhone 3 作为一个团队，出了这种 bug 都有责任，不管是开发测试还是项目经理。除了运维，谁也不可能把自己完全撇清责任。 再重复一遍，开发产品测试项目经理都有责仁。 但责任也分主次。如果这种需求设计纰漏的主要责任人甩给开发，就等同于将代码逻辑 bug 的主要责任人甩给产品一样可笑。 遇到这类问题会发火也是人之常情，但一般都是骂：“现在也是什么 s [哔] 也能当产品经理了。前端看到这种需求请往死里怼”。不骂产品反而骂开发，只会让人觉得：“不愧是产品，甩锅技术一流” |
 | 90 alphatoad 2019-07-12 06:40:26 +08:00 只允许国内身份证和国内手机号注册的服务都是屑。 只支持微信支付和支付宝的服务都是屑。 每次回国跟打仗一样，斗智斗勇 |
 | 91 greatghoul 2019-07-12 08:09:05 +08:00 说实话，前端不背这个锅。 |
 | 92 xiaolanger 2019-07-12 08:19:38 +08:00 一个产品，吐槽的时候，都分不清前后端的责任，这算是直接暴露了产品的本质吗？ |
 | 94 sugars PRO 前端同学有苦说不出呀，不背锅，反正我的手机正则支持 166 /^(13[0-9]|14[579]|15[0-3,5-9]|16[6]|17[0135678]|18[0-9]|19[89])\d{8}$/ |
 | 95 l00t 2019-07-12 08:29:32 +08:00 1 连拒需求都不会？这开发当得也太怂了。 |
 | 96 sarices 2019-07-12 08:32:32 +08:00 后端也要验证啊，你要不要跟后端说说？ |
 | 97 encro 2019-07-12 08:52:00 +08:00 1 10000000000<n>19999999999 |
 | 98 jzmws 2019-07-12 09:15:24 +08:00 我之前的一个项目 ，手机号校验过不去 ，后面改成直接 1 开头的十一位 |
| 99 yhxx 2019-07-12 09:16:20 +08:00 原来楼主是产品，那就能理解了。。。 正常情况下哪个开发会愿意写这么复杂的校验需求，还要区分 18xxxxx 可以，16xxxxx 不行 直接校验 11 位数字一把梭多简单粗暴 这种东西大部分情况下都是产品严格要求才会做的吧？ 稍有质疑就是“用户体验“ 然后回到主楼的问题，新上线的产品一般不会有这种问题吧？ 至于旧的，还不是你们当年要求这么做的？ |
 | 100 ethusdt &nbp; 2019-07-12 09:18:02 +08:00 网上随便找一个排名靠前的手机号正则, 用自己的手机号测试通过, mock 几个手机号测试也通过, 上线发版. Test code in production. 于是发现部分号段手机号主人反馈不能发送验证码, 经调查, 网上正则是 10 年前过时的答案, 于是连带着测试扣绩效吧.. |
Select Language