具有大量持久内存使用量的 Chrome 扩展 MV3，可能吗？

如何解决具有大量持久内存使用量的 Chrome 扩展 MV3，可能吗？

我正在开发一个 Chrome 扩展程序，该扩展程序旨在检查用户导航到的任何网页的内容，然后提醒用户该内容的某些“功能”。 （也许最容易想到在网页的文本数据中搜索的大量字符串，尽管这是一个相当大的简化。）按照设计，有一个非常大的集合（数千万）扩展程序检测到的功能，因此可以对其做出反应。每个这样的特性都可以表示为一个 JS 编号（8 个字节），因此数据总量可能在 100 MB 或更多。

该数据可以存储在 IndexedDB 中，但是为了能够快速分析页面数据（由内容脚本发送），后台页面脚本（在 MV2 中）或 service worker（在 MV3 中）确实需要具有存储在 RAM 中的特征（已检查），以便能够从网页中快速检查小得多但仍然大量的特征，以查看其自己的数据集中是否存在这些特征。

这个设置在我创建的原型清单版本 2 (MV2) 扩展中实际上运行良好。后台脚本将首先从 IndexedDB 获取数据并将其放置在 RAM 中的结构中。这在我的笔记本电脑上需要一些时间（一些秒数，我没有精确的数字）但只需要在浏览器启动时完成一次。之后，后台脚本可以快速响应内容脚本的请求，检查网页内容。

现在，在尝试过渡到清单版本 3 (MV3) 时，问题在于 Service Worker 不是持久的，甚至不是特别长寿。因此，每次重新启动时，直接转换都会让 Service Worker 执行从 IndexedDB 到 RAM 的昂贵且缓慢的加载。这显然不是一个有效的设置。

那么明显的问题是：有没有办法避免 Chrome 停止服务工作者（从而让扩展服务工作者持续很长时间）？如果没有，是否有某种方法可以让 RAM 中的数据保留下来，并且服务工作者在启动时获取对它的访问权限？ （我远非 Chrome 扩展和服务工作者方面的专家，所以如果我的问题很幼稚，我深表歉意。）我阅读了一些讨论，似乎表明上述两种方法目前都不可能，但如果是这样，它基本上会使整个概念在 MV3 下非首发。有什么解决方法吗？ （如果是，Chrome 网上应用店审核流程中是否可以接受这些变通方法？）

如有任何指点，我将不胜感激！