在前幾篇我們學了怎麼建環境、寫路由、處理參數。今天要聊的主角是 Middleware（中介層）。
聽起來有點抽象？別擔心，想像我們又回到速食店點餐的場景。

Middleware 是什麼？

想像一下你去速食店：

1. 你走到櫃檯（請求進入伺服器）
2. 店員先檢查訂單（是不是有奇怪的要求，像「咖啡不要洋蔥」）
3. 店員問你要不要加套餐（額外服務）
4. 訂單才被送去廚房（Handler 處理邏輯）
5. 廚房做出餐點（伺服器產生回應）
6. 店員交餐點並附上發票（回應送回給使用者）

這些「檢查」或「加值動作」就是 Middleware。
它可以在請求進來之前幫忙，也能在回應送出之後再加工。

如果沒有 Middleware，你就得在每個 Handler 裡都自己加上「檢查訂單、加套餐、印發票」的程式碼，最後整個專案變得超亂。

Middleware 的目標就是：把共用的規則抽出來，讓主程式碼乾淨俐落。

Echo 中的 Middleware 有什麼用？

Echo 幫我們準備了一堆常見 Middleware，舉幾個例子：

• Logger：每次請求都記錄下來，像「誰點了什麼、花多久上菜」。
• Recover：防止程式因為 bug 直接掛掉。
• CORS：允許跨域請求，讓不同網域的前端也能叫到 API。
• RequestID：給每個請求一個專屬編號，方便追蹤。
• Authentication：檢查使用者有沒有登入、有沒有資格點餐。

實戰演練

1. Logger Middleware

e := echo.New()
e.Use(middleware.Logger())

e.GET("/", func(c echo.Context) error {
    return c.String(http.StatusOK, "Hello, World!")
})

請求一進來，終端機就會印出一行 log：

2023-10-27 10:30:00 GET / 200 13 0.000012s

2. Recover Middleware

e := echo.New()
e.Use(middleware.Recover())

e.GET("/", func(c echo.Context) error {
    panic("Oops!") // 故意出錯
    return nil
})

有了 Recover → 伺服器安然無恙，只回給你一個「500 內部錯誤」。

3. RequestID Middleware

e := echo.New()
e.Use(middleware.RequestID())

每個請求都會有自己的 ID，就像每張發票都有號碼。

4. CORS Middleware

e := echo.New()
e.Use(middleware.CORS())

這就像餐廳開放「外送平台」接單。

Middleware 可以疊加

e.Use(middleware.Logger())
e.Use(middleware.Recover())
e.Use(middleware.RequestID())

這就像一條流水線：

1. Logger 記錄 →
2. Recover 防呆 →
3. RequestID 打編號 →
4. Handler 真正處理

自訂 Middleware：打造專屬規矩

假設你想讓 API 只在上班時間能用（09:00–18:00）。

func CustomTimeCheckMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        hour := time.Now().Hour()
        if hour < 9 || hour >= 18 {
            return c.JSON(http.StatusServiceUnavailable, map[string]string{
                "message": "抱歉，目前不在服務時間內，請明天再來！",
            })
        }
        return next(c)
    }
}

結語

Middleware 就像速食店的「隱形規矩」：

• 先檢查（Logger / Authentication）
• 防呆（Recover）
• 加服務（CORS / RequestID）
• 自訂規則（上班時間才營業）

透過 Middleware，你的程式會變得乾淨、可維護，而且更有彈性。