Manifest V3浏览器扩展如何实现内容脚本与DevTools面板可靠通信

Manifest V3 下后台 Service Worker 会被系统按需休眠回收，内存里存的长连接端口、临时变量全会被清空，这是官方的设计预期，不是bug。靠定时重置连接的方案本质是跟浏览器资源回收机制对着干，既不稳定也不符合扩展开发规范。

DevTools 类扩展自带专用通信API，根本不需要经过后台脚本做消息转发，彻底规避SW休眠问题：

• DevTools 面板可以直接通过内置API和被调试页上下文通信，不需要经过扩展后台层
• 整套通信链路完全事件驱动，没有轮询开销，不会因为后台休眠断连

核心实现逻辑：

• 从 DevTools 面板发消息到 Content Script：调用DevTools专属API直接在Content Script上下文触发自定义事件传参
• 从 Content Script 发消息到 DevTools 面板：通过控制台输出带特殊标识的结构化日志，DevTools面板监听控制台消息事件过滤解析即可

核心代码示例：

// ========== DevTools 面板侧代码 ==========
// 接收来自Content Script的消息
chrome.devtools.inspectedWindow.onConsoleMessage.addListener((messageText) => {
  if (!messageText.startsWith('__DEVTOOLS_EXT_TAG__:')) return
  const message = JSON.parse(messageText.slice('__DEVTOOLS_EXT_TAG__:'.length))
  // 在这里处理业务逻辑
})

// 发送消息到Content Script
function sendToCS(payload) {
  const evalCode = `
    window.dispatchEvent(new CustomEvent('__EXT_DT_MSG__', {
      detail: ${JSON.stringify(payload)}
    }))
  `
  chrome.devtools.inspectedWindow.eval(evalCode, {
    useContentScriptContext: true
  })
}

// ========== Content Script 侧代码 ==========
// 接收来自DevTools面板的消息
window.addEventListener('__EXT_DT_MSG__', (e) => {
  const payload = e.detail
  // 在这里处理业务逻辑
})

// 发送消息到DevTools面板
function sendToDT(payload) {
  console.log(`__DEVTOOLS_EXT_TAG__:${JSON.stringify(payload)}`)
}

如果你的业务逻辑必须经过后台Service Worker处理，不要用定时器轮询保活，按照SW的生命周期设计适配即可：

• 绝对不要在Service Worker的内存里存储任何需要持久化的状态、长连接端口引用，所有会话状态全部存在chrome.storage.session存储中，SW重启后数据不会丢失
• 所有事件监听器必须同步注册在SW的顶层作用域，不要放在任何异步回调里，保证SW被事件唤醒时能第一时间触发监听器
• 不需要主动维持长连接：只要任意一端发消息，SW会被消息事件自动唤醒，唤醒后先从session存储里读取未处理的消息队列，检查目标端连通性，重建必要的端口连接后再投递消息即可，整个过程完全由事件触发，没有空转开销

不要尝试用无限期保持runtime端口连接、空轮询等方式强制SW保活，这类方案已经被Chrome判定为违规行为，会被系统强制休眠，严重时可能导致扩展无法通过商店审核

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