前三天都是路由寫好就直接回應，今天碰Express很核心的概念-Middleware（中介函式），理解請求進來後，怎麼在真正處理之前先攔截下來做點事。

今天做的事
在所有路由之前加入一個Middleware，讓每次請求都先經過這裡，記錄下請求資訊跟處理時間：

//Midleware
app.use((req, res, next) => {
  const start = Date.now();
  res.on('finish', () => {
    const duration = Date.now() - start;
    console.log(`${req.method} ${req.url} - ${duration}ms`);
  });
  next(); //必須要呼叫，不然請求會卡住
});

測試 /、/about、/success、/notfound，終端機印出：

GET /notfound -27ms
GET /success -2ms
GET /about -2ms
GET / -2ms

拆解程式碼在做什麼

• app.use(...)註冊了一個Middleware，沒有指定路徑，代表每一個近來的請求都會先經過這裡，不管是/還是/notfound
• next是Middleware特有的第三個參數，呼叫next()才會把請求繼續往下傳給對應的路由處理，如果忘記寫，請求會卡住，瀏覽器就會一直轉圈圈載入不出來
• res.on('finish', ...)是監聽這次回應已經送出去了的事件，這時候才能準確算出從收到請求到處理完成花了多少時間

心得
原本以為每個請求的處理時間應該差不多，結果第一次測試/notfound花了27ms，後面幾個卻只要2ms，時間明顯短了很多。查一下，猜測因為第一次執行時Node.js跟Express都還在暖機（如載入模組、初始化一些內部機制），之後的請求才會進入穩並的處理速度，這跟系統剛啟動時第一次操作通常比較慢的經驗蠻符合的。
另外理解Middleware之後回頭看，發現前三天寫的console.log印出請求資訊，其實也可以直接寫成Middleware的形式，統一放在最前面，而不是每個路由都各自處理，這讓我體會到Middleware存在的意義：把每個請求都要做的共同邏輯抽出來一次寫好，而不是在每個路由裡重複貼一樣的程式碼。