什麼是快取？應用程式建構者的白話指南
快取是保留一份現成副本，讓原本既慢又昂貴的資料，下次被請求時能從這份副本快速回應。這份保存下來的副本稱為快取（cache）。瀏覽器會快取圖片，讓網站第二次造訪時載入更快；伺服器則會快取慢速資料庫查詢的結果，避免每位訪客都要重新執行一次。
快取能讓應用程式更快，執行成本也更低。它最大的取捨是：副本可能會過時。
用 AI 開發時，為什麼快取很重要
在 AI 開發的應用程式中，你會以三種方式遇到快取：
- 「我更新了應用程式，但看到的還是舊版本。」 這是最常見的快取情境，通常無傷大雅：你的瀏覽器或 CDN 正在顯示保存的副本。
- 速度。 如果頁面變慢是因為每位訪客都要重新計算相同的數字，快取計算結果就能讓它感覺像是瞬間載入。
- 成本。 許多 AI 建構工具與主機會對運算、資料庫時間和外部 API 呼叫收費。如果一千位訪客都觸發同一個昂貴的請求，快取能讓你只需付一次費用。
了解基本概念，你就能在適當的地方要求使用快取，也能在快取正是某個現象的原因時及時發現。
日常生活的比喻
想像一間忙碌咖啡店的廚房。
每天早上，咖啡師可以在客人點餐時才用新磨的咖啡豆沖每一杯咖啡，但這很慢。於是他們會在保溫盤上備好一壺濾滴咖啡。大多數客人幾秒鐘就能拿到咖啡——這就是快取命中（cache hit）。等壺裡的咖啡喝完，有人就要重新沖一壺——這就是快取未命中（cache miss）。
但咖啡放太久會走味，所以這間店定了一條規則：超過 30 分鐘的咖啡壺就丟掉。這條規則就是快取的到期時間。沒有人會整天都用同一壺咖啡，也不會預先沖好客人特製的燕麥奶加三匙糖——有些東西根本不該被快取。
快取存在哪裡
一次頁面載入可能會經過好幾層快取，從離使用者最近到最遠依序是：
| 快取 | 位置 | 通常儲存的內容 | 範例 |
|---|---|---|---|
| 瀏覽器快取 | 在訪客的裝置上 | 圖片、樣式表、腳本、字型 | 第二頁時，你的標誌會立即載入 |
| CDN 快取 | 分布在世界各地、靠近訪客的伺服器 | 靜態檔案，有時也包括整個頁面 | 東京的訪客從附近的伺服器取得檔案，而不是從你的來源伺服器 |
| 應用程式快取 | 在伺服器上或其旁邊，通常位於記憶體或 Redis 中 | 慢速查詢或外部 API 呼叫的結果 | 今天的匯率，每小時抓取一次 |
| 資料庫快取 | 在資料庫內部 | 最近被使用的資料與查詢計畫 | 熱門資料列留在快速記憶體中 |
CDN（內容傳遞網路）本質上就是一個遍布全球、用來快取你網站檔案的快取網路。
快取如何決定要保留什麼
每一種快取都必須回答同樣的問題：
- 什麼可以被快取？ 公開的共用資料（例如產品圖片、部落格文章）——可以。私人資料（例如使用者的帳號頁面、訊息）——絕不能放在共用快取中。
- 快取多久？ 這就是 TTL（存活時間，time to live）。標誌可能快取一年；庫存量可能只快取 30 秒。
- 如何更新？ 要不是副本到期後重新抓取，就是資料變動時應用程式主動移除副本——稱為失效（invalidation）。
對於網站，伺服器會用 Cache-Control 標頭告訴瀏覽器與 CDN 每個檔案該如何快取。例如，Cache-Control: max-age=3600 的意思是「這份副本一小時內可以重複使用」。
現代的建置工具會用**快取破壞（cache busting）**來處理靜態檔案中最困難的部分：每次檔案變更時，它都會得到一個帶有指紋的新檔名，例如 app.3f9a2c.js。瀏覽器可以長時間快取舊的檔名，因為新版本的檔名本來就不同。
實例：一個小型產品目錄
你經營一間小型線上商店。首頁會從資料庫顯示 50 項產品的價格與庫存，另外還有一個「熱門」清單，需要對所有訂單做一次緩慢的計算。
- 圖片與腳本由瀏覽器和 CDN 長時間快取。每次建置都會讓變更的檔案得到新名稱，因此更新仍然會顯示出來。
- 熱門清單每 10 分鐘計算一次，並儲存在應用程式快取中。那 10 分鐘內的每位訪客都會立即取得儲存的結果。
- 價格只快取一小段時間，而且每當你編輯產品時就清除快取，因此客人不會長時間看到舊價格。
- 結帳時的庫存絕不快取。當有人按下「購買」時，應用程式會查詢真正的資料庫，因此不會賣出剛剛售罄的商品。
- 購物車與帳號頁面絕不存放在共用快取中，因為它們屬於個人資料。
結果：首頁很快，資料庫的工作量大幅減少，而且任何與金錢或隱私相關的內容都不會過時。
關鍵名詞
| 名詞 | 意義 |
|---|---|
| 快取命中／未命中 | 資料在快取中找到了／必須從來源重新取得。 |
| TTL（存活時間） | 快取副本被視為新鮮的時間長度。 |
| 過期資料（Stale data） | 已經過時的快取副本。 |
| 失效（Invalidation） | 因為原始資料已變更而主動移除快取副本。 |
| 快取破壞（Cache busting） | 檔案變更時改變其檔名或網址，讓快取抓取新版本。 |
| Cache-Control | 告訴瀏覽器與 CDN 如何快取回應的 HTTP 標頭。 |
| 強制重新整理（Hard refresh） | 重新載入頁面，並要求瀏覽器忽略其快取。 |
| Redis | 常見的記憶體內資料儲存服務，經常用作應用程式快取。 |
常見的誤解
- 「快取永遠是好的。」 快取錯誤的東西會造成真正的 bug：舊價格、新文章不見、或最糟的情況——某位使用者的私人頁面被另一位使用者看到。請審慎地決定要快取什麼。
- 「如果看到舊版本，代表我的更新失敗了。」 通常並非如此。在假設出了問題之前，先試試強制重新整理（Ctrl+Shift+R，或 Mac 上的 Cmd+Shift+R），或改用私密視窗。
- 「快取能修好慢速的應用程式。」 快取只是把重複請求的慢速隱藏起來。第一次請求仍然很慢；如果根本的問題是缺少資料庫索引，也要一併修正。
- 「我應該盡可能長時間快取所有東西。」 較長的快取時間適合那些內容變更時會更換檔名的檔案。對於 HTML 頁面與資料，較短的時間比較安全。
- 「清除我的快取就能讓所有人都正常。」 這只會清除你的瀏覽器。訪客與 CDN 快取仍然保有它們自己的副本。
該向你的 AI 建構工具要求什麼
- 「這個應用程式哪些部分很慢？哪些可以安全地快取？」
- 「把[熱門清單／API 結果]快取 [N] 分鐘，並在底層資料變更時清除它。」
- 「確保任何包含個人或帳號資料的頁面都不會被 CDN 或共用快取快取起來。」
- 「對附有指紋的靜態檔案設定較長的快取時間，對 HTML 則設定較短的時間。」
- 「快取來自[外部 API]的回應，避免每次載入頁面都呼叫它——並告訴我這些資料可能會過時多久。」
- 「發布後我看到舊版本。這是我的瀏覽器快取，還是有東西沒有部署？」
Mythex 中的快取
發布 Mythex 應用程式的更新後，文件提到 CDN 快取可能會稍微延遲；對公開網址進行強制重新整理，就能看到新版本——請參閱如何發布。託管限制頁面也建議快取靜態資源，因為主機、資料庫時間與頻寬都是從你的點數餘額中扣除的。超出這些範圍的做法——例如快取查詢結果或 API 回應——則是你要求代理程式在應用程式中建構的功能。
延伸閱讀：什麼是 CDN、如何讓你的網站更快，以及什麼是速率限制。
常見問題
用簡單的話說，什麼是快取？
快取是把取得時既慢又昂貴的東西保存一份副本，下次需要時就能直接從保存的副本快速提供。瀏覽器、CDN、伺服器和資料庫都使用快取，讓應用程式更快，也更省錢。
我更新了網站，為什麼還是看到舊版本？
你的瀏覽器或 CDN 很可能正在提供舊檔案的快取副本。強制重新整理（Windows 上按 Ctrl+Shift+R，Mac 上按 Cmd+Shift+R）通常就能解決。對訪客來說，設計良好的網站會為更新後的檔案產生新的檔名，讓快取自動抓取新版本。
清除快取會做什麼？
清除瀏覽器快取會刪除瀏覽器儲存的檔案與頁面副本，讓下次載入時全部重新下載。這可以修復看起來壞掉或過時的頁面，不過清除後第一次載入會稍微慢一點。
快取會造成問題嗎？
會。最主要的風險是提供過期的資料，例如舊價格、過時的庫存量，或更糟的情況：把某位使用者的私人頁面快取起來，並顯示給別人看。良好的快取規則會決定哪些內容可以快取、快取多久，並且絕不在共用快取中快取個人資料。