當運營向我們上報BUG時，我們第一時間是捕獲相關的接口。從[監控系統](https://www.cnblogs.com/strick/p/14577054.html)中，就可以查到用戶使用時接口的請求和響應數據。   若接口的請求正常，那么就需要深入到接口代碼中，查看相關的日志，通常會先瀏覽數據庫查詢語句以及內部接口的通信日志。   在本地也可以查看到上述日志，但有個問題，有時候打開某個頁面會報錯，那是因為本地的數據庫沒有與測試或正式環境的同步。   可能是有些字段缺失了，也可能是某張表缺失了，情況比較多。所以，最保險的是在測試或正式環境查看。   在這兩個環境中，都有日志管理系統，但日志量是非常巨大的，若要查找某一條記錄，就得有非常精確的過濾條件，并且日志無法連續。   這條日志下面的一條，很可能是另外一個接口留下的，因此，需要一個小工具能查看到指定接口的日志，解決日常開發的一個痛點。 ## 一、搜集日志 **1）管理系統**   首先需要將需要的日志搜集起來，我使用了一個比較簡單的方法。   就是在啟動文件中，新增一個全局的logMessages變量，聲明為一個空數組。 ~~~ global.logMessages = []; ~~~   然后在MongoDB、MySQL、請求內部接口函數中，將他們的查詢語句日志和通信日志塞入logMessages數組內。 ~~~ mongoose.set('debug', (...args) => { logger.debug(...args); global.logMessages.push(args); }); new Sequelize(database, username, password, { ...options, logging: (msg, benchmark) => { logger.debug(msg, `${benchmark}ms`); global.logMessages.push(msg); } }); ~~~   再新增一個中間件（Server項目基于KOA2），這個中間件的作用就是清空logMessages數組，免得將所有接口的日志都搜集起來，因為我只要一個接口的日志。 ~~~ export default () => async (ctx, next) => { //每次請求清空要讀取的日志數組 global.logMessages.length = 0; await next(); }; ~~~   這么設計會有一個問題，服務器在處理多個請求（高并發）時，互相會影響各自的日志搜集，可能會出現這個接口日志中夾雜著另一個接口的日志，也可能是搜集到一半的日志就被清除了。   當然，在測試環境，這種情況可以控制住。但是測試環境有時候數據不完整，邏輯可能走不下去，得上生產環境，那生產環境就有概率出現上述問題。   后面將中間件去除，logMessages變量在一個接口中聲明，這個接口就是下面界面中點提交時請求的接口，能解決日志被無故清除的問題，但還是會出現串線的問題。   生產環境暫時無解，好在還有一個預發環境，它使用的數據源和生產是相同的，只要保證代碼和生產同步，那么就能得到想要的日志列表。 **2）Web API**   Web API是另一個接口服務，也需要監控其中的日志，但是它與之前的管理系統不同，它是一個獨立的服務。   也就是說，我無法直接在管理系統中通過 global.logMessages 讀取日志。   一開始是想將日志寫入緩存中，然后在管理系統中讀取緩存中的日志，不過這樣做不僅太繞，平添復雜度，而且日志寫法也會與之前的不一致。   于是否決了此方案，改用一個中間件，日志的寫入和讀取與之前保持一致。不同點是在一個中間件中，將日志作為響應的參數返回。   在下面的代碼中，當需要日志時，我會帶上一個特殊的參數：isLogMessages，只有這個參數存在時，才表示需要返回記錄。 ~~~ export default () => async (ctx, next) => { // 只有帶了特殊參數的請求，才會把接口日志帶上 const isLogMessages = ctx.query.isLogMessages || ctx.request.body.isLogMessages; if(isLogMessages) { global.logMessages = []; } await next(); if(isLogMessages) { const { body } = ctx; if(typeof body === 'string') { ctx.body = { data: body }; }else { ctx.body = { ...body } } ctx.body.logMessages = global.logMessages; delete global.logMessages; } ~~~ ## 二、界面   在完成上述的日志搜集之后，就需要有一張操作界面（如圖所示），提升我們組自己的用戶體驗，借助之前封裝的[模板組件](https://github.com/pwstrick/shin-admin/blob/main/docs/template.md)，搭建這樣一個頁面幾十分鐘就好了。 :-:    界面中包括API路徑、方法、項目和參數，其中參數可動態增加，點擊提交就會開始模擬請求接口，得到日志（如圖所示）和響應。 :-:    這樣一套操作之后，就能馬上知道接口內的細節，可幫助我們快速定位問題，也是一種降低時間成本的手段。 ***** > 原文出處： [博客園-Node.js躬行記](https://www.cnblogs.com/strick/category/1688575.html) [知乎專欄-Node.js躬行記](https://zhuanlan.zhihu.com/pwnode) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。