20200221 工作中遇到奇怪的问题

问题

一个我负责维护ETC充值圈存服务的程序。

今天收到这样的反馈，一个线上的用户遇到了这么一个奇怪的问题：绑卡操作的时候填的车牌号是云A12345，操作也成功了。于是查看已绑定卡列表信息，结果看到显示的车牌号是云A21345。解除卡绑定之后，重试上面的操作，也是一样的结果。

第一反应，我是懵逼的。这在我看来就好比我在评论区留言写了abc，结果显示的是bca。更神奇的数据库里存储的也是bca。而且这个程序好几个月没改过了。不应该有这样的问题啊。而且要真的出问题，应该全部用户都会出现这样的问题才对啊。

虽然想不懂。不过也工作一年多了，奇奇怪怪的问题遇到的也不算少了，也相信科学！肯定是有原因的。

分析、解决

首先是用户的截图。确实是绑卡操作填写了云A12345，确实也提交成功了。查看已绑卡列表信息时确实也是显示了云A21345。

登上服务器查看日志，日志是不会骗人的。一看，绑卡接口的入参确实写的是云A12345，紧接着执行的查看已绑卡列表信息接口的出参确实显示的是云A21345。看到这里的时候我懵了好一会。（有毒吧这是？？）

于是回头看代码，原来有这么个逻辑：绑卡接口会去调ETC发行方的接口，调用成功后，会做入库操作。如果是数据库中不存在这个卡号，则会把卡号、车牌号等其他信息存储到绑卡表中。如果该卡号之前做过绑卡操作，则直接更新绑定状态字段。（PS：一个车牌号码和一张ETC卡是一一对应关系）

于是，根据log日志查询了该用户调用过的所有接口。发现用户19号也做过绑卡操作（今天是22号）。也就是说，今天绑卡操作填的云A12345，跟数据库绑卡表里的存储的云A21345是没有关系的。也就是说，我要去找到这个第一次绑卡的时候填写的车牌号码（一个卡号，只有在第一次执行绑卡操作的时候才会执行insert操作，否则执行的是update绑定状态字段）。

顺着日志，找到了第一次执行绑卡操作是在19号。并且填的车牌号码确实就是错误的云A21345。但是，新增绑卡记录操作是在调用ETC发行方接口之后。这种情况，在调用ETC发行方时应该是返回车牌号码与卡号不匹配才对啊。

于是一问，原来刚好那天他们的服务也出了点问题。所以导致了填写了错误的车牌号码也能操作成功。因此在执行新增绑卡记录的时候就把错误的车牌号码存到数据库中。然后用户今天又来操作，解绑卡不需要用到车牌号，重新绑卡也没用到车牌号。数据库里存着的一直都是错误的车牌号。因此查看卡列表信息的时候显示的绑定的车牌号码就是错误的车牌号码。

于是，问题就解决了。只要把数据库里存储的错误的车牌号码改成正确的就OK的。

最后

说实话，能感觉到自己确实有在进步。哈哈。共勉。