前幾天在測試的時候發現一個bug，剛開始還很莫名奇妙，反覆找原因都找不到，後來分析請求和返回報文的時候，才發現這個問題產生原因。為了讓大家可以少走彎路、少掉坑，這邊和大家一起分享一下。

應用場景：

app可以用手機號來兌換別的系統金幣，運營平臺擁有修改繫結手機號的功能。正確的流程應該是運營平臺修改使用者對應的繫結手機號之後，兌換產生的分值也會發放到我們已經修改後的手機號碼中。

bug場景：

在測試的過程中就發現一個問題，不管我們怎麼修改繫結手機號，兌換的一直都是第一個繫結的手機號碼。只有當app重新整理的時候，重新進入兌換頁面才會用修改後的繫結手機號，進行分值兌換。

問題分析：

剛開始以為是對方系統出現問題了，後面發現分值可以兌換成功，只是號碼不是我們最新繫結的號碼。然後繼續分析，也有可能是運營平臺修改沒有成功，但是檢視資料庫，發現確實是已經成功了。最後根據app那邊反饋過來的情況，最終定位為有可能app是直接拿快取的繫結手機號，來進行分值兌換操作，查詢一下app請求報文，發現還真實這個問題。

方案制定：

這種情況其實很好解決，app那邊不需要傳繫結的手機號來兌換，只要傳一個使用者id，然後服務端通過這個使用者id，去查詢對應的繫結手機號，然後通過查詢到的繫結手機號去兌換。這樣就可以保證每次使用者兌換，都是最新修改那個繫結手機號了。

問題反思：

問題是已經解決了，但是我們不能僅僅解決問題就可以了，一定要思維擴充套件、舉一反三，看看系統中有沒有可能存在類似的情況，火速找到馬上解決，然後分析產生這樣問題的原因。之所以會產生這樣的bug，最根本的原因就是：沒有拿不變的引數來請求服務端介面，這句話的意思是：app介面請求的時候千萬不要拿一個可能會被修改的欄位作為請求引數，一個要拿一個不可改變的引數作為請求引數，通俗的來說就是要拿不具備時效性的資料來請求。

總結：

看了上面的例子，以後大家要是遇到類似的應用場景，一定知道怎麼處理了吧。剛剛說到舉一反三，其實電商系統中有很多這樣的例子，比如提交訂單，我們在訂單預覽的時候，可以看到這一單所對應的積分值，但是千萬不要直接拿這個預覽的積分值作為實際的積分值，一定是傳一個訂單id（不具備時效性），然後通過後臺自己去計算積分值。好了今天的內容就介紹到這邊了，謝謝大家的閱讀～

要更多幹貨、技術猛料的孩子，快點拿起手機掃碼關注我，我在這裡等你哦~