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

Question

我在安装事件中使用服务 worker 和预缓存 Assets 。

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

问题:为什么即使它是请求/响应存储，也为该 json 数据使用缓存 API 不是一个好习惯？

我问这个的原因是因为我尝试了以下内容:我有 index.html and main.js在 install 中预缓存事件并在 main.js我有 axios请求返回一些 json 并将其放入 index.html .如果我使用动态缓存，这意味着当向该 json api 端点发出请求时，它会首先发送到我的服务 worker ，它会获取响应并将其放入 cache .然后我对其进行了测试，当在离线模式下刷新页面时，我仍然得到相同的结果(json 数据相应地放在 index.html 中)。

所以我猜即使缓存 API 存储请求/响应，它仍然可以完美地适用于 json 端点 api url。

任何好主意为什么在使用服务 worker 时更喜欢 indexeddb 而不是缓存 API？

Answer 1

使用缓存存储 API 缓存 JSON 数据是非常好的，作为使用 IndexedDB 的替代方法。我希望有类似的性能特征，在这两种情况下，您都可以从 service worker 或 window 读取/写入数据。语境。
如果您有尚未与 Response 关联的 JSON 数据，则使用缓存存储 API 会稍微尴尬一些。对象，或者没有“真实”请求 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);