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

Question

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

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

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

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

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

知道为什么在使用服务工作者时更喜欢 indexeddb 而不是缓存 API 吗？

Answer 1

使用缓存存储 API 缓存 JSON 数据非常好，作为使用 IndexedDB 的替代方法。我希望有类似的性能特征，在这两种情况下，您都可以从 Service Worker 或window上下文读取/写入数据。

如果您有尚未与Response对象关联的 JSON 数据，或者没有“真实”请求 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);