为什么对动态内容使用 indexeddb 而不是缓存 api

Question

我在安装事件中使用服务工作者和预缓存资产。

我还有 fetch 侦听器，它会在运行时动态拦截请求和缓存。我知道人们说将 indexeddb 用于动态内容，例如 json 数据和可能的图像。

问题： 为什么对 json 数据也使用缓存 API 不是一个好习惯，即使它是 request/response存储？

我问这个的原因是因为我尝试了以下操作：我在 install 事件中预缓存了 index.html and main.js，在 main.js 中我有 axios 请求returns 一些 json 并将其放入 index.html。如果我使用动态缓存，这意味着当对 json api 端点的请求被发出时，它首先到达我的服务工作者，它获取响应并将其放入 cache。然后我测试了一下，当在离线模式下刷新页面时，我仍然得到相同的结果（json 数据相应地放入 index.html）。

所以我猜即使缓存 API 存储 request/response，它仍然可以完美地用于 json 端点 api url。

知道为什么在使用 service worker 时更喜欢 indexeddb 而不是缓存 API 吗？

Answer 1

使用缓存存储 API 缓存 JSON 数据非常好，作为使用 IndexedDB 的替代方法。我希望有相似的性能特征，在这两种情况下，您都可以 read/write 来自服务工作者或 window 上下文的数据。

如果您有 JSON 数据尚未与 Response 对象相关联，或者没有有一个“真实的”请求 URL，因为您必须有效地“伪造”它们。但这并不是特别难做到：

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);

为什么对动态内容使用 indexeddb 而不是缓存 api

why to use indexeddb instead of cache api for dynamic content

javascript

service-worker

workbox

angular-service-worker