上週接了一個任務，處理線上的一個bug，看似簡單的問題，如何快速的定位解決是很考驗人的時刻。線上問題如下：
線上大部分的數據是沒有問題的，只有這一組數據出現了問題，so，問題的關鍵就在於如何定位了，接下來便是深入基層，從頁面開始查看調用了那個方法，之後進入業務端代碼，真正的大戲開始了，如果是新手對業務和代碼都不熟悉，這會是一個很煎熬的時刻（自己就是這樣的……）。所以你就必須一條一條業務去跟，一個一個接口去看，之後就是根據接口查找正真的數據來源來自哪個庫表，循環往復，一遍遍地跟蹤纔可能對新的業務和數據有所瞭解。如果夠幸運的話在這個過程中便可以發現和解決一些小的問題，但是碰到一些古怪的bug還是需要很深的內功的，那就需要另闢蹊徑了。
從表面現象來看的話是頁面數據加載出錯，但是具體什麼錯誤我們不知道，這是我們可以將詳細的錯誤信息打印出來，以便定位問題出在哪裏，例如自己的XMLHttpReq.status值爲500，所以可以確定問題出現在業務端。
當然這個的前提是可以在開發環境模擬線上環境來進行這些工作，這當中模擬線上環境，模擬線上的數據就是非常非常重要的一關，需要多業務熟悉、還有就是每一個業務會涉及到那些數據，纔可以完整復現線上的問題，這個過程只能慢慢修煉了，當開發環境的數據都模擬完畢之後，打印XMLHttpReq的信息便可以初步確定錯誤來自前段頁面還是業務端代碼，當然我們也可以從其他頁面的返回值來確定是不是頁面有錯誤，但是打印XMLHttpReq的信息畢竟是很專業的方法。如果確認前端沒有問題，再接下里就是一步步去業務端跟代碼了，業務端的問題也是千奇百怪，但是如果可以到了能夠針對問題單步調試的程度，最終肯定能夠定位問題的所在。
以上就是自己調試線上問題的一些思路和經驗，這個過程中經歷了很大的時間壓力還有上司壓力，這種壓力會給自己解決問題帶來負面的影響，但是我們能做的就是把“鴨梨”放進冰箱裏，變成“凍梨”……如果日誌寫的比較好的話，線上問題很多時候也可以通過日誌來定位，所以還需要結合具體的情況來定位問題，後期自己也會介紹一下線上日誌定位問題的一些思路和步驟，盡請期待！