V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
leafiy
V2EX  ›  分享发现

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

  •  2
     
  •   leafiy · 2019-07-11 16:33:14 +08:00 · 17630 次点击
    这是一个创建于 1997 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    第 1 条附言  ·  2019-07-11 18:28:37 +08:00
    付解决方案:

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

    2.国际产品带国家前缀的: https://github.com/google/libphonenumber
    第 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 画的不漂亮你咋不反应一下? 」这种问题的,如果我能获取这种能力,应该快可以买房了。
    146 条回复    2020-02-15 12:37:12 +08:00
    1  2  
    123s
        101
    123s  
       2019-07-12 09:23:42 +08:00
    打车 APP 推给前端
    wolfie
        102
    wolfie  
       2019-07-12 09:24:50 +08:00
    火气真大,而且真能杠。
    前后端应该是相同的验证吧,这跟前端无关,跟你的 LGBT 同胞也无关。
    tanranran
        103
    tanranran  
       2019-07-12 09:28:55 +08:00   ❤️ 3
    13000000000<n>19999999999
    huochebaka
        104
    huochebaka  
       2019-07-12 09:29:42 +08:00
    前端要有预测未来的能力还在这里写代码?
    ChuangChang
        105
    ChuangChang  
       2019-07-12 09:31:12 +08:00
    13000000000<n>19999999999
    这个回复需要最多赞,谢谢咯
    ChuangChang
        106
    ChuangChang  
       2019-07-12 09:31:33 +08:00
    @tanranran 哈哈哈,撞上了
    momocraft
        107
    momocraft  
       2019-07-12 09:34:23 +08:00
    手机号已经是正则能用的地方了

    你看每天都有人在研究怎么用正则解析上下文无关文法
    hyy1995
        108
    hyy1995  
       2019-07-12 10:03:04 +08:00
    作为一个前端,个人来讲,如果产品原型里面没固定手机号码限制,那么一律 /^1\d{10}$/一把梭就完事了
    whypool
        109
    whypool  
       2019-07-12 10:21:30 +08:00
    input max-length=11

    要啥正则
    loading
        110
    loading  
       2019-07-12 10:24:21 +08:00 via Android
    你不能怪大家,因为我们也只会直接用库里面的验证,哈哈。
    fakeJas0n
        111
    fakeJas0n  
       2019-07-12 11:19:03 +08:00
    出租车排队 10000 个人?
    royzxq
        112
    royzxq  
       2019-07-12 11:22:24 +08:00
    屁股都是歪的谈何讨论
    leoleozhu
        113
    leoleozhu  
       2019-07-12 11:28:04 +08:00
    国外手机号怎么处理,前端同学怎么做得这么不友好
    MyouiSouth
        114
    MyouiSouth  
       2019-07-12 11:34:13 +08:00   ❤️ 1
    讨论着讨论着就开始气急败坏。。。
    leafiy
        115
    leafiy  
    OP
       2019-07-12 11:51:03 +08:00
    @123s 没看到讨论的是微信端和小程序吗?
    @MyouiSouth 因为我先描述不准确所以都是产品的锅,和其他人没关系
    @leoleozhu google 那个库先解析一次
    @fakeJas0n 抱歉没有仔细数精确到 1
    @huochebaka 产品要有预测未来的能力还在这里做产品?
    lzj307077687
        116
    lzj307077687  
       2019-07-12 11:57:30 +08:00
    自从前几个月发现有 166 后 干脆 1+10 个数字
    huochebaka
        117
    huochebaka  
       2019-07-12 12:07:13 +08:00
    @leafiy 我可没说拜托产品同学们不要再用正则验证手机号了
    edsheeran
        118
    edsheeran  
       2019-07-12 12:15:40 +08:00 via iPhone
    @leafiy pm 不考慮未來的改動對目前產品的影響,還做什麼 pm,拉低天朝 pm 平均水平
    leafiy
        119
    leafiy  
    OP
       2019-07-12 12:24:01 +08:00
    @wolfie 对嘟嘟,都是产品的错,我早就说了
    leafiy
        120
    leafiy  
    OP
       2019-07-12 12:24:37 +08:00
    @edsheeran 我觉得未来应该没有显示器了,所以现在开始都丢掉吧
    expy
        121
    expy  
       2019-07-12 12:43:22 +08:00
    这个还有风控方面的考虑吧,有的号段被羊毛党、黑产之类的大量使用。
    leafiy
        122
    leafiy  
    OP
       2019-07-12 13:01:16 +08:00
    @expy 据我了解,这方面的问题好一点的服务商都已经完成了,咱们终端产品不用多心。就算被黑产利用,这也应该从产品内部逻辑解决吧
    nicoljiang
        123
    nicoljiang  
       2019-07-12 13:26:28 +08:00
    其实好多情况,都不一定刻意。而是随意找了个库、正则套用了。
    然而这一切在 QA 和验收环节都不一定能测不出来的。

    PS:网上得到方法、类、(尤其)正则,不靠谱的真是十之六七。
    laoertongzhi
        124
    laoertongzhi  
       2019-07-12 13:27:14 +08:00
    ……,这吐槽得真「有趣」
    cccRaim
        125
    cccRaim  
       2019-07-12 14:21:03 +08:00
    我也是业务中发现需要更新手机号正则,考虑到未来会更新很多次,然后就干脆不验证了,只验证第一位和长度,楼主的思维很合理,不知道为什么那么多人喷
    windsgone
        126
    windsgone  
       2019-07-12 14:24:26 +08:00
    这里回复的有产品吗?
    我是产品,也非常讨厌手机号的正则判断,所以不会提这个需求,最多是首位为 1
    另外说句,我遇到过前端会自己加上正则判断,可能是找的代码,有一次导致客户不能注册还被坑了
    所以不要都甩锅产品...
    大家都是为了用户服务,有好的不好的都可以互相提是不是
    raptor
        127
    raptor  
       2019-07-12 14:34:54 +08:00
    支持楼主,活干得糙就是干得糙,一看到别人批评就跳出来甩锅的人,怕是啥也干不好——除了摸鱼。
    kazeik
        128
    kazeik  
       2019-07-12 15:13:23 +08:00
    我是开发,我也不想写,,但测试人员给我打了一个 bug..
    .........
    一个 bug .....
    说 12345678900 这号码咋通过的
    BCy66drFCvk1Ou87
        129
    BCy66drFCvk1Ou87  
       2019-07-12 15:29:35 +08:00
    +1,我的也是 166 开头的新手机号,很多网站 /APP 的号码正则都没覆盖
    orm
        130
    orm  
       2019-07-12 15:38:30 +08:00
    说个有意思的事儿,联通公众号:沃安全,开通防骚扰服务,输入我的 166 开头的联通号码,告诉我电话号码有误
    orm
        131
    orm  
       2019-07-12 15:42:21 +08:00
    redbuck
        132
    redbuck  
       2019-07-12 16:38:32 +08:00
    假设你买了台电车,跑回老家或者哪里犄角旮旯,找不到充电桩你是怪电车厂家没给你搞个太阳能充电还是怪自己太傻?

    尝新本来就是有得有失的.
    leafiy
        133
    leafiy  
    OP
       2019-07-12 17:14:58 +08:00 via Android
    @redbuck 思路清奇,这两件事的尝试成本和解决成本有可比性吗
    N1ceHua
        134
    N1ceHua  
       2019-07-12 18:03:15 +08:00
    +1;同样 166 号段,遇到很多服务网站和 APP 的手机号码验证不通过,专门给发了邮件提醒他们及时更新验证条件,还给我回复了邮件并表示感谢。
    neverandy
        135
    neverandy  
       2019-07-12 18:14:31 +08:00
    正则不背这个锅
    neverandy
        136
    neverandy  
       2019-07-12 18:14:58 +08:00
    问题在思维,不在技术
    leafiy
        137
    leafiy  
    OP
       2019-07-12 18:29:03 +08:00 via Android
    @neverandy 得得得,没人有锅,错的是我
    gongzili456
        138
    gongzili456  
       2019-07-12 18:58:19 +08:00
    根据 Fail-fast 原则,我从来不做规则校验
    redbuck
        139
    redbuck  
       2019-07-12 22:20:27 +08:00
    @leafiy 我只是指出你这种自我中心的心态而已。

    不过你表演了这么多楼,我想大家也都看清楚了。
    leafiy
        140
    leafiy  
    OP
       2019-07-12 22:35:43 +08:00
    @redbuck nice! 看我表演买单了吗?
    leafiy
        141
    leafiy  
    OP
       2019-07-12 23:17:27 +08:00
    @redbuck

    好久没喷人了,正好有空就来爽一爽吧。

    先就你 132L 的回复,注意就事论事哦。

    ① 假设你买了台电车 与 使用新号段手机号
    答:情景类似,但不同之处在于「电车」是可作为一般存在的并自主选择权很大。新号段并不属于尝试新鲜事物,用户对于号段的选择并不 100%自主。诸如新入校学生,公司集团号码,国际友人来国内临时使用等等等情况都可能被安排新号段。所以可对比性不强。

    ② 跑回老家或者哪里犄角旮旯 与 使用互联网产品
    答:都是对自己所已经拥有的事物进行使用。同样,骑电车跑回老家,对老家有无充电设施应该有 2 个心里预期「有」 or 「没有」。而使用互联网产品,我认为用户对产品限制号段没有心里预期,也不存在应对措施。


    ③ 找不到充电桩你是怪电车厂家没给你搞个太阳能充电还是怪自己太傻?
    答:这个就很好回答了,既然你喜欢对比我也整几个「斗鱼游戏主播买了 MacBook12 直播游戏」是苹果的错还是用户的错。「强移动办公商业人士使用全顶配外星人出门恰谈生意」是戴尔的错还是用户的错。「罗太君驾驶特斯拉西藏自驾游」是马斯克的错还是罗太君的错。对比结束。
    找不到充电桩,是因为②中用户的自主选择且用户很难自行给出解决方案,风险和承担风险的心里是同时存在的。新号段不能使用某些产品,没有相关知识的用户不会认为这是自己原因造成的,因为别的手机号可以使用,很可能造成用户对产品的公平性产生质疑从而造成用户流失,比如主贴中的国际友人,当我接到他电话时说的最多的就是:its not fair , I've done nothing wrong。

    综上,你的对比并不成立。

    然后回应 139L,我很不理解自我中心的心态我表现在哪里了?还望指出。

    我表演了很多楼?我知道你在说楼上为我说话的几位,好吧是我的小号,整个 v2 我有 100 多个账号而且都是前 10000 注册,羡慕吗? livid 见我都要低头三分

    (正经脸:感谢楼上几位,其实我不认为开发人员有甩锅习惯,我比较不喜欢的风气是很多开发真的把自己当 IDE 了,一个产品做得好需要所有人员一起努力,这一点我在 2 个月前 V2 招人的面试中 v2 深有感触,单就把自己当 IDE 这一点隔壁贵乎风气都比 v2 好多了)
    redbuck
        142
    redbuck  
       2019-07-13 10:44:33 +08:00
    @leafiy 啧啧啧
    zhouweiluan
        143
    zhouweiluan  
       2019-07-13 11:02:58 +08:00
    @leafiy 思路清晰,老哥赞你。
    foundyou
        144
    foundyou  
       2019-07-13 15:32:17 +08:00
    @leafiy #141 赞一个,另外说一句,越是以自我为中心的人,才越对别人的自我中心越是敏感
    no1xsyzy
        145
    no1xsyzy  
       2019-07-15 13:47:26 +08:00
    附言 2: [红白黑黄] (幻视)
    jaylee4869
        146
    jaylee4869  
       2020-02-15 12:37:12 +08:00
    发现了 128 号段的。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2706 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 12:32 · PVG 20:32 · LAX 04:32 · JFK 07:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.