最近工作有點忙碌，遇到了兩次莫名不知如何解決的錯誤，由此暴露的問題讓人不禁反思：

?

好的分析排查習慣比問題本身更值得關注。

?

首先是前天晚上遇到的一個問題是這樣的：

我需要定時去從redis的zset里面取得一些key，然后查詢數據庫，得到一些原始數據，再通過外部的一些webservice去發送微信消息，通知到相關用戶。由于取出來的key可能是多個，所以在最外層我是包了一層for循環，整個代碼都是promise化的異步（nodejs技術棧）

?

在發送微信消息之前的步驟里面我每個關鍵部分都有log輸出，然而最后還是遇到了報錯，運行到調用webservice發送請求之后，腳本無輸出了很長一段時間，然后打印出了out of memory的js stack信息。我最開始的思路是去google查詢相關錯誤信息的解決辦法，然而這種堆棧報錯更多是因為循環回調太深造成內存耗盡，一般出現在數據量較大的循環調用中，而我在測試的時候只有一條數據，應該不是這個表面造成的原因。

?

按照一般的思路，我開始增加更多的日志，一段一段去屏蔽代碼，在最后一次輸出正確之后的代碼往往是問題所在。而那一段是使用superagent發送post請求的代碼塊，我單獨屏蔽之后發生沒有報錯，于是我單獨寫了一個測試腳本來運行這段post請求，然而并沒有報錯。走到這里我開始感覺郁悶和無奈，到底錯在哪里？

?

后面去請教后端老大，他首先格式化了一下我的代碼，讓代碼更整潔（由于使用的是簡單ide，寫多了就會有些亂)。之后他提醒我在每一段promise段中增加catch代碼，因為我嵌套了多個promise對象操作，而有一部分并沒有最終return出來，所以有些error可能沒有catch到。

在增加這些異常捕獲之后還是沒發現問題，之后關注重點就回到post請求，先修改了返回延遲，然后終于打印除了response，最終發現了問題所在是因為post的數據不符合superagent內部解析方式，而因為請求容忍時間太長了，導致了內存異常不能暴露出真正問題。

?

其實我已經確認了問題所在，但沒有繼續深挖以及完善日志記錄。而且在重現問題寫單獨腳本的時候，我并沒有使用相同的數據作為測試，而是寫死了一個測試數據，最終沒能暴露出真相。

?

還原現場的前提是：

?數據、條件、邏輯三者保持完全一致。

?

第二個遇到的問題是：

?

突然前端同學找到我，說某單獨部署的項目出現了不能正常生成一些數據，每次都報:Not a string or buffer的錯誤。首先我拿到這個問題也是去理清邏輯和增加必要log，然而那段報錯信息太少了，我最終也排查到了錯誤段，又一次遇到了和之前那個問題一樣無法更進一步的窘境。

?

最終也是在老大的協助下，通過使用console.error(e|| e.stack) 打印出了堆棧錯誤信息，追蹤定位到了出錯的文件和文件行，發現是由于配置文件造成無法加密出salt，造成TypeError報錯。

?

總結：調試的思路和方法需要多注意，catch中多使用console.error打印堆棧信息而不是簡單的Log.感謝團隊的同事以及老大耐心地幫助，我也會好好反思，提高自己。

轉載于:https://www.cnblogs.com/freephp/p/7220688.html

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的一叶障目：排查问题的思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。