今天运营反映了一个问题：用户在微信小程序端提交实名认证信息时，提示“不支持信用卡”。
直觉告诉我们，既然提示是“不支持信用卡”，那看来用户输入的银行卡号是信用卡。接下来直接去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. 这些与你的技术水平无关，日常开发中，稍加严谨一些，这些不必要的问题都可避免。
《漂洋过海来看你》 填 词：李宗盛 谱 曲：李宗盛 为你我用了半年的积蓄 飘洋过海的来看你 为了这次相聚 我连见面时的呼吸都曾反复练习 言语从来没能将我的情意 表达千万分之一 为了这个遗憾 我在夜里想了又想不肯睡去 记忆它总是慢慢的累积 在我心中无法抹去 为了你的承诺 我在最绝望的时候 都忍着不哭泣 陌生的城市啊 熟悉的角落里 也曾彼此安慰 也曾相拥叹息 不管将会面对什么样的结局 在漫天风沙里 望着你远去 我竟悲伤得不能自己 多盼能送君千里 直到山穷水尽 一生和你相依