【工作記錄】記一次問題排錯和解決過程

今天下午配合前端那邊聯調接口，接口是用部署在服務器上的，但是這個時候，報錯了，如何在服務器上排查錯誤，經歷的少，這個過程浪費了不少的時間。所以這次記錄一下，保證明天不再犯類似的錯誤。

一、日誌文件的路徑和位置

第一個攔路虎：「你以爲的日誌路徑？」

我查看了項目中的路徑，又去服務器上看了路徑，我就以爲是這個/log/live-chat-web-api.log，然後利用swagger調用該方法，發現還是調用不通。最後看了看日誌，發現最新日誌還是2017年10月份的，所以接下來，我又問了問同事，具體的文件路徑，才發現，日誌文件的路徑是不對的。（浪費了10分鐘，教訓慘痛）

二、linux系統下查看服務器日誌命令不熟悉

 如何實時查看log文件，命令是 ：tail -f  live-chat-module-users.log

還是對於linux命令的每個的含義是什麼，不太清楚，所以總是忘記，用到的時候，就得馬上查。所以今後一定要牢記，這裏也浪費了時間。

三、報錯問題不敏感

下面是用swagger做接口測試，報的錯誤如下：ForI input String :\"string\",很明顯的錯誤信息，輸入格式問題。但是因爲不太確定，服務器上也找不到，所以我本地服務上也跑了一遍，仍然是報同樣的錯誤。然後我確定應該是數據格式的問題。

但是我認真檢查了一遍，跟項目中modle的屬性對應了一遍，發現全都一樣的啊。最後求助於同事，同事一眼就看出來了。是字段LanguageId的問題。model中類型定義如下：

所以swagger中傳遞的也是string類型。

但是實際上在使用的過程中，languageId是多個int類型數字，用逗號分隔組成的字符串。類似於「1,3,34」匹配而成的字符串，

所以傳遞的應該是內容是int類型的字符串。

更改之後，問題解決。

啓發：

問題很明顯，但是沒有考慮到多個int類型的拼接。

四、查看報錯日誌的技巧，如何定位錯誤

解決了第一個問題，第二個問題又過來了。接口報500，我及時定位了錯誤，如下圖：

根據getAdSwitch 顯示行數，是218行，去項目代碼中搜索，確定方法位置。然後看代碼，要去查找對應appId和platform的數據。然後會從list中獲取一條（list.get(0)）,應該是未獲取到值，然後導致的空指針。

驗證猜想，

用傳遞的參數去mysql中查詢指定的數據，果然數據爲空，更改傳遞的參數，測試成功。

啓發：

這個思路過程中還是比較清晰的，繼續加油。

四、小結

      下午聯調過程中，問題真是百出，感謝同事們的幫助，最後全都解決了。在這個過程中，親身實踐，收穫很多，包括對於自己的思路和技術積累。其實想想，問題真的很小，但是就是這麼小的問題，自己竟然解決不了，很慚愧。

這個下午，心驚膽戰，很難過，又有解決問題之後的喜悅。

   繼續加油和努力，既然逃不掉，就拋開臉皮，像漢子一般的向前衝。