問題
一個我負責維護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的。
最後
說實話，能感覺到自己確實有在進步。哈哈。共勉。