Chrome扩展MV2迁MV3时使用chrome storage持久化数据的最佳方案

Service Worker终止前触发事件说明 #

Chrome目前没有提供Service Worker即将进入非活跃（终止）状态的可靠触发事件。beforeunload、unload这类页面端常用的事件在Service Worker环境下完全不适用，Chrome的Service Worker终止逻辑是强制触发的，不会保证这类事件的回调执行完成，因此完全不能依赖这类事件做收尾存储操作。

Manifest V3下数据持久化最佳实践 #

方案1：实时防抖写入存储（最推荐） #

不要将数据长期缓存在Service Worker的全局变量中，每次数据更新时直接触发存储逻辑即可。这种方式虽然看起来存储逻辑分散，但完全符合Manifest V3的设计规范，可靠性最高。
如果担心频繁写入带来的性能损耗，可以加一层防抖处理，示例代码如下：

// 防抖存储工具，300ms内多次更新只会触发一次真实写入
const debounceSave = (() => {
  let saveTimer = null;
  return (newData, delay = 300) => {
    clearTimeout(saveTimer);
    saveTimer = setTimeout(() => {
      chrome.storage.local.set(newData);
    }, delay);
  };
})();

// 所有数据更新的位置调用该方法即可
debounceSave({ tabs: currentTabsData, document: currentDocData });

方案2：会话存储做兜底缓存 #

如果确实需要保留内存缓存提升访问效率，可以同时将数据同步写入chrome.storage.session，该存储区域的生命周期和Chrome实例完全一致，即使Service Worker被销毁重启，也可以快速从chrome.storage.session中恢复缓存数据，不需要每次都读取持久化的chrome.storage.local。

方案3：临时延长Service Worker生命周期（仅特殊场景使用） #

如果存在未完成的长耗时任务，可以通过定期发送空的chrome.runtime.sendMessage消息、或者保持长连接端口的方式临时延长Service Worker的存活时间，但不建议长期使用该方案，不符合Manifest V3的性能设计原则。

分散存储逻辑的合理性说明 #

分散写入是Manifest V3下的标准实现方式，完全合理。Manifest V3本身的设计就是要求开发者放弃原有Background Page长期存活的思路，适配Service Worker按需启动、随时终止的生命周期，实时/防抖写入的方案已经被大量主流扩展验证过稳定性，不需要担心逻辑分散带来的问题。

内容的提问来源于stack exchange，提问作者Swetha