Chrome扩展MV3：休眠唤醒后Service Worker概率重启，如何实现MV2式持久化？

针对Chrome 109（Win7）的临时缓解方案 #

• 强化Offscreen页面与SW的双向通信
  原方案的单向postMessage在系统休眠唤醒后可能无法快速重建活跃链路，改为双向通信能更稳定维持SW存活：

  // Offscreen页面代码
  setInterval(() => {
    chrome.runtime.sendMessage({ type: 'keep-alive' }, () => {});
  }, 10000);
  
  // Service Worker代码
  chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
    if (msg.type === 'keep-alive') {
      sendResponse({ ack: true });
    }
    return true; // 保持消息通道开放
  });
  

  双向通信能让Chrome持续识别SW处于活跃状态，休眠唤醒后Offscreen页面的定时器会立即恢复通信，降低SW重启概率。

• 状态持久化模拟“无重启”体验
  即使SW不可避免重启，通过chrome.storage.local持久化应用状态，启动时快速恢复工作流程：

  // Service Worker启动时恢复状态
  chrome.runtime.onStartup.addListener(async () => {
    const { appState } = await chrome.storage.local.get('appState');
    if (appState) {
      // 恢复之前的业务逻辑，比如重新注册监听、启动任务等
      restoreAppState(appState);
    }
  });
  
  // 定期保存应用状态
  setInterval(async () => {
    await chrome.storage.local.set({ appState: getCurrentAppState() });
  }, 60000);
  

新版本Chrome的修复情况 #

Chrome 116及后续版本针对系统休眠唤醒场景下的Service Worker稳定性做了优化，大幅减少了无必要的SW重启。但Win7仅支持到Chrome 109，无法直接享受这些修复，只能通过上述方案缓解问题。

关键注意事项 #

• 不要依赖setInterval作为核心保活手段，Chrome会在SW闲置时静默终止定时器，优先结合Chrome Alarms与Offscreen通信实现保活。
• Offscreen页面需遵循MV3规范设置"persistent": false，通过持续通信维持其活跃状态，避免被Chrome主动终止。

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