前言

昨天我們追蹤了 Identifier.php 的程式碼，理解了 Magento 是怎麼產生 Redis key。
但光看一段程式碼還不夠，我們還需要把它放進整個 Request → Response 的流程裡，才能真正看懂快取是怎麼工作的。
今天就來分享：Magento 的 HTTP 請求流程，以及 Page Cache 插手的時機。

流程一：快取存在時（Cache Hit）

當使用者請求一個頁面，Magento 的流程大致是這樣：

1. index.php
   所有 HTTP 請求的入口。

2. bootstrap.php
   啟動 Magento 2。

3. http.php
   進入 HTTP 請求處理的核心。

4. BuiltinPlugin.php (module-page-cache)
   這裡會檢查 request 的 identifier 是否已存在快取。

   • 如果存在 → 直接回傳快取內容，整個系統不需要再跑下去。

5. Response
   頁面立刻送回給使用者，超省效能 🚀。

流程二：快取不存在時（Cache Miss）

1. Request 進來
   使用者的 HTTP 請求經過 index.php → bootstrap.php → http.php。

2. BuiltinPlugin.php 插手檢查

   • 這裡先用 identifier 去 Redis 查 cache。
   • 如果不存在，就讓請求繼續往下跑（也就是圖上紅色箭頭）。

3. frontcontroller.php

   • 解析 URL，決定要呼叫的 module 與 controller。
   • 例如分類頁就會對應到 Magento\Catalog\Controller\Category\View。

4. Magento 執行邏輯並產生 Response

   • 讀資料庫、組合 layout、渲染 HTML。
   • 產生完整的 response。

5. BuiltinPlugin.php 再次插手

   • 在 response 返回時，BuiltinPlugin 會檢查 response 的 Header 是否允許被快取（例如 X-Magento-Tags、Cache-Control）。
   • 如果允許，就會 save 這份 response 到 Redis，並用剛剛那個 identifier 當 key。

6. Response 回傳

   • 頁面送回使用者。
   • 下次同樣的請求就能直接在步驟 2 命中 cache。

也就是說，這裡的重點有兩個：

• 第一次檢查（Cache Miss → 繼續執行 Magento）。
• 第二次檢查（Response 出來後，如果可快取 → 存進 Redis）。

我們觀察到的重點

• 快取判斷點很早（在 frontcontroller 前面），能大幅省下後端資源。
• Identifier 就是關鍵：它決定了這個 request 是否「等同」於之前的快取結果。
• Cache Miss 時也不會浪費：Magento 會自動把結果存起來，準備下次使用。

結語

現在我們把「快取在哪一步介入」講清楚了：
Magento 的 Full Page Cache 是在 HTTP request 一進來時就攔截，並根據 identifier 決定是否命中。

昨天我們知道 identifier 太敏感，會導致重複快取；
今天我們看到它實際影響整個流程。

👉 明天我們就要繼續挑戰：
能不能優化這些 identifier，避免 Redis 裡塞滿重複資料？