血压飙升！记一次关于手机号存储的前后端讨论

起

事情是这样的，有一款产品需要实现国际化的注册需求，界面如下 ：

涉及到的手机号码，因为要区分国家区号，所以和手机号是分开的，前端形态是分开存储的。一开始数据确实也是分开存的，么的问题。

本来是很简单的表单需求，结果出了幺蛾子。

承

对于前端来说，这就是两个字段，在表单传值和数据逻辑处理时，直接用两个字段无疑是最直接和简单的：

const formData = {
    country_code: '86',
    phone: '13345431234'
    ...
}

但是，产品侧有一个强需求：手机号和其他的两个字段要做唯一性校验，不但要求三个至少存在一个，而且还要查别的业务库的数据表来校验这个注册人员的唯一性，有一套复杂的逻辑。总结一下就是，后端分开两个字段来判断很麻烦，这个也好理解，有耦合的逻辑重构要成本的。所以后端是这么要求数据的：

// (86)13345431234
phone: `(${country_code})${phone}`

将国家码放在前缀括号里拼接为一个字符串。这样一来，前端的成本就相对高了一些，不但在表单提交时要拼接，而且在列表查询时，要按照括号匹配解析出前缀来动态显示。

const regex = /^\((\d+)\)(\d+)$/;
const matches = phoneNumber.match(regex);
// 如果匹配成功，返回国家码和号码的数组
if (matches) {
    const countrycode = matches[1];
    const number = matches[2];
    return [countrycode, number];
}

就算这样，也可以接受，之前也不止一次挖过这种自己拼接自己解析的坑了。但是随后就有点让人血压上升了。

转

由于业务扩展，上面的手机号，要传递给一款即时通讯软件 xxx 的 API 来做下发，下发侧则规定了，需要不带括号但是要有国家区号前缀的手机号码：

// 8613345431234
phone: `${country_code}${phone}`

这就有问题了，我们直接对接的后端需要括号的，下发侧对接的后端同学不需要括号。

第一阶段

血压上升 20%

讨论让后端换成两个字段存储，这样更灵活，方便拼接；或者给下发侧发数据时去掉括号也可以。后端很为难：”唯一性判断还有其他的逻辑很复杂，有耦合性，拆开字段就要重构，工期又紧，刚完成就要改，误了工期只有我背锅；去掉括号不是不可以，但地方有点多，还要考虑批量数据的性能，而且已经进入测试了，不接受临时需求“。我一想有道理啊，就去问下发侧同学。

第二阶段

血压上升 60%

问下发侧对接的同学，可以处理后再给 API下发吗？果断拒绝。他们也有理由的：”按照软件设计的规范，我们不应该非标处理这个问题的，下发的规范理应就是我们接口的规范，因为规范还有很多，这个地方妥协了，以后肯定还会有更多的非标处理，我们的代码就乱了。“

我草，我一想之前那那么多屎山的由来，觉得更有理了，那怎么办？弄得好像前端这里没有理了。

第三阶段

🔥 血压上升 120% 🔥

下发侧对接的同学反过来给我们前端提了建议，让我们在注册的时候，把前端两个字段就直接不用括号来拼接给后端，在需要解析的时候，使用特别手段解析出国家码。还好心的给我们搜索了一个解析手机号的 js 库：

我只能说，我 TM 谢谢你。😭

前端莫名其妙的凭空多了需求，而且加个库为了给后端擦屁股，还增加了打包体积，出了问题我们得首先背锅，这肯定不行。

合

这起事件牵涉的技术问题并没有多难，甚至有些幼稚，但是却蕴含了不少上班族哲学，最主要的一点是：如何学会背锅的问题。锅不是不能背，但是背锅换来的应该是产品成功后更多的功劳回报，而不是这种暗箱操作，老板压根不知道，只有扛不住的人吃暗亏。

个人觉得，这个应该是架构师或者技术总监的任务，提前了解上下游业务，并确定好字段与数据结构，而不是等用的时候才发现数据对不上。规划好用什么方案来开发。并将方案设计交于老板开会讨论得出定稿。之后再分派人员开发，就不会有这个事件了。

类似的问题还有很多，前后端与下游计算价格进制与单位不统一，每次都要非标转换；

最后的结局，产品出面调停，软磨硬泡，最终后端妥协了，夹在前端和下发侧之间, 确实为难。针对前端还是原来的逻辑不动，使用括号存储，他在下发侧拉取数据的时候做转换，去掉括号。其中涉及的性能问题和开发成本也申请了延长工期。

Happy Ending ！！😁

血压恢复 0%

附

方案设计注意事项：

• 注意产品迁移的问题。同类型的产品，如果针对的客户群体不同，其表现形态可能完全不一样，产品迁移过程中，要提前分析出新产品的业务场景的差异，做好风险分析。
• 提前确定产品上下游生态，做好风险管控。比如下发侧有 API 对接的，需熟悉其 API 文档与使用限制，并在服务不可用时设计告警方案等。