為什么對動態內容使用 indexeddb 而不是緩存 api

Question

我在安裝事件中使用服務工作者和預緩存資產。

我還有fetch偵聽器，它會在運行時動態攔截請求和緩存。 我知道人們說將 indexeddb 用於動態內容，例如 json 數據和可能的圖像。

問題：為什么即使它是請求/響應存儲，也為該 json 數據使用緩存 API 不是一個好習慣？

我問這個的原因是因為我嘗試了以下內容：我在install事件和index.html and main.js中預緩存了index.html and main.js main.js我有axios請求，它返回一些 json 並將其放入index.html 。 如果我使用動態緩存，這意味着當對該 json api 端點發出請求時，它首先進入我的 service worker，它獲取響應並將其放入cache 。 然后我測試了一下，當在離線模式下刷新頁面時，我仍然得到相同的結果（json 數據相應地放在 index.html 中）。

所以我猜即使緩存 API 存儲請求/響應，它仍然可以完美地用於 json 端點 api url。

知道為什么在使用服務工作者時更喜歡 indexeddb 而不是緩存 API 嗎？

Answer 1

使用緩存存儲 API 緩存 JSON 數據非常好，作為使用 IndexedDB 的替代方法。 我希望有類似的性能特征，在這兩種情況下，您都可以從 Service Worker 或window上下文讀取/寫入數據。

如果您的 JSON 數據尚未與Response對象關聯，或者沒有“真實”的請求 URL，那么使用緩存存儲 API 會稍微有點尷尬，因為您必須有效地“偽造” “ 他們。 但這並不是特別難做到：

const data = {
  // some data
};
const jsonString = JSON.stringify(data);

const jsonResponse = new Response(jsonString, {
  headers: {
    'content-type': 'application/json',
  },
});
const cache = await caches.open('json-cache');
await cache.put('/some-json-url', jsonResponse);