不注重开发细节，活该你忙！

今天运营反映了一个问题：用户在微信小程序端提交实名认证信息时，提示“不支持信用卡”。

直觉告诉我们，既然提示是“不支持信用卡”，那看来用户输入的银行卡号是信用卡。接下来直接去auth生产库的卡bin表查证，却发现此卡是借记卡。

 

 显然，是程序出了问题。

我们看如下用户实名信息提交的处理时序，可见，卡bin验证的链路涉及到bosskg-api、bosskg-rpc-provider、auth-gateway、auth-channel四个服务。其中，bosskg-rpc-provider、auth-gateway、auth-channel还都是双节点。查找原因要从每个服务的log文件来定位。

 

 

 

 一顿查询后，原来竟然是由于卡号带有空格导致的。如下是auth-channel程序最终执行的sql。因为这个空格，导致未能检索到那条卡bin数据。

SELECT card_bin_id, card_bin, card_bin_len, card_len, card_bin_st, card_type, bank_code, iss_ins_cd, iss_ins_nm, card_nm, operator, reg_time, mod_time FROM card_bin 
WHERE card_bin = SUBSTRING('6214922000037188 ',1,card_bin_len) AND card_len=LENGTH('6214922000037188 ') LIMIT 1;

接着，再来看bosskg-api的请求log，果然，用户输入的卡号末尾包含了一个空格字符！而bosskg-rpc-provider的在接收到auth响应之后的判断逻辑是：如果 !"01".equals(cardBin.cardType)，则返回“不支持信用卡”，而并没有判断cardBin.cardType是否为空值。这样的逻辑，最终误导了我们对问题的判断。

 

真相大白了！

我们有理由抱怨用户的“粗心”吗？

运营人员可以跟客户反馈，别输入空格。

之于我们程序员，之于我们的程序，我经常强调，还是要兼容用户的输入。就拿卡号来说，首先一定要先做trim处理，其次，要兼容卡号中间带有空格的情况。另一个同样不容忽视的改进点，是上面的对响应结果的判断逻辑。

否则，当我们在排查问题时，对于复杂的分布式系统，往往会非常耗费时间。

 

easier said than done. 这些与你的技术水平无关，日常开发中，稍加严谨一些，这些不必要的问题都可避免。

 

---

 

 

《漂洋过海来看你》

填    词：李宗盛
谱    曲：李宗盛

为你我用了半年的积蓄
飘洋过海的来看你
为了这次相聚
我连见面时的呼吸都曾反复练习

言语从来没能将我的情意
表达千万分之一
为了这个遗憾
我在夜里想了又想不肯睡去

记忆它总是慢慢的累积
在我心中无法抹去
为了你的承诺
我在最绝望的时候
都忍着不哭泣

陌生的城市啊
熟悉的角落里
也曾彼此安慰
也曾相拥叹息
不管将会面对什么样的结局

在漫天风沙里 望着你远去
我竟悲伤得不能自己
多盼能送君千里
直到山穷水尽
一生和你相依