在Chrome和Firefox中，扩展使用的IndexedDB是持久的。在Chrome中，即使没有添加"unlimitedStorage"到"permissions"，它也是无限的，所以它使用全局配额管理，请参见crbug.com/1209236。我导入了一个虚拟的40 MB JSON（压缩15 MB），它工作正常。Safari WebExtensions规范可能没有那么慷慨。
使用IndexedDB的原因：

1. structured clone algorithm支持的非字符串键和值（Map、Set、Date、RegExp、Blob、File、FileList、ArrayBuffer、ImageBitmap、ImageData，以及最近的BigInt、Error），以及chrome.storage.local和.sync提供的基本JSON兼容类型（字符串、数字、布尔值、空值以及递归地由这些平凡类型组成的数组/对象）。
   1.存储和阅读大的或深嵌套的对象可以轻松地快10倍甚至更多。
   1.检查键的存在而不阅读其值。
   1.只阅读键的名称而不读取它们的值。
   1.用几个关键字编索引。
   1.为每个不可预测的增长或收缩的数组指定一个完整的object store（或多个），这将比阅读整个数组、修改它并写回chrome.storage中的单个键快很多倍（如果数组很大，甚至可能快1000倍）。
   扩展的IndexedDB不能直接在内容脚本中使用，只能通过解决方法：

• 在Chrome ManifestV 2中，它被限制为JSON兼容类型，因此要传输复杂类型，您必须将其字符串化（慢）或者通过new Response将数据转换为Blob，将其馈送到URL.createObjectURL，发送结果URL，确认收到后撤销。Chrome'的ManifestV 3将支持消息soon的结构化克隆算法，但它们的实现仍然在内部限制克隆数据，因此在修复之前，处理大量数据肯定会很慢。

Firefox不受此限制，AFAIK。

• 网页中的iframe，其中src指向通过web_accessible_resources在其manifest.json中公开的扩展的html页面。（在Chrome中）在扩展进程中运行，因此可以直接访问其存储，并且可以使用parent.postMessage，后者支持结构化克隆算法，发送结果。为了避免被页面拦截，您应该在document_start运行内容脚本，以便在页面之前以捕获模式附加侦听器，并防止其侦听器看到事件：

// this script must be declared with "run-at": "document_start"
const extensionOrigin = chrome.runtime.getURL('').slice(0, -1);
window.addEventListener('message', e => {
  if (e.origin === extensionOrigin) {
    e.stopImmediatePropagation(); // hide from the page
    console.log(e); // process the event
  }
}, true); // register in the first phase, "capture"

但是这还不够！站点可以在扩展安装之前安装监听器，因为WebExtensions实现中存在一个基础安全漏洞（在Chrome和Firefox中观察到），允许页面修改新创建的同源iframe或tab/window的环境，请参见crbug.com/1261964，因此对于敏感扩展，您必须实现非常复杂的变通方案，直到这个漏洞被修补。ManifestV 3将提供一个安全的postMessage，该postMessage仅限于内容脚本的“隔离世界”。