Chrome扩展runtime消息交互无响应排查，Manifest V2开发场景

问题根因 #

你遇到的响应丢失问题核心是两个原因共同导致的：

1. 重复注册消息监听器冲突
   你在background配置和popup.html中都引入了同一个functions.js，相当于同时在扩展的背景页上下文、弹窗上下文两个独立环境中注册了完全相同的chrome.runtime.onMessage监听器。
   当content script（product.js）发送跨上下文消息时，所有活跃的扩展上下文都会收到这条消息。Chrome的消息响应规则是：只要有任意一个监听器执行完毕且没有显式声明需要保留响应通道，Chrome会立刻关闭响应通道，后续其他监听器调用的sendResponse都会直接失效。只要你的扩展弹窗曾打开过、弹窗上下文处于活跃状态，就会触发这个冲突，导致product.js的回调无法触发。
2. 监听器未显式声明保留响应通道
   即便没有重复注册的问题，如果你的监听器后续可能异步调用sendResponse（哪怕你当前是同步调用），也需要在监听器函数末尾显式返回true，通知Chrome不要提前关闭响应通道。你当前的代码没有加这个返回值，也会增加响应丢失的概率。

修复方案 #

第一步：拆分监听器代码，避免重复注册 #

把functions.js中消息监听的逻辑抽离到仅会被background加载的独立脚本中，删除popup.html中对functions.js的引入（如果你确实需要在popup中使用部分工具函数，把工具函数和背景专属的消息监听逻辑拆分为两个不同的文件即可）。

第二步：补全监听器返回值，保障响应通道可用 #

修改background端的消息监听代码，补全return true，同时对不存在的localStorage字段做兜底处理，避免返回undefined：

// 仅在background加载的消息监听脚本
chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) {
  console.log(request) 
  console.log(sender)
  console.log(window.localStorage)
  if (request.method == "getStatus") {
    sendResponse({status: localStorage['opt-disable'] ?? false});
  } else {
    sendResponse({msg: "hello"});
  }
  return true; // 关键：通知Chrome保留响应通道直到sendResponse被调用
});

第三步：添加错误检测逻辑，方便后续排查 #

修改product.js的消息发送代码，增加运行时错误捕获，避免异常被静默忽略：

// product.js
$(function(){
  chrome.runtime.sendMessage({method: "getStatus"}, function(response) {
    // 捕获消息发送阶段的错误
    if (chrome.runtime.lastError) {
      console.error("消息调用失败：", chrome.runtime.lastError.message);
      return;
    }
    console.log(response);
    if(response.status != 'true'){
      // 执行业务逻辑
    }
  });
});

Manifest V3迁移注意事项 #

你后续迁移到Manifest V3时需要注意两点：

1. V3的背景上下文替换为Service Worker，不支持localStorage，需要改用异步的chrome.storage.localAPI读写存储
2. 使用异步存储后，return true的声明就成为必填项，否则响应通道会在存储异步返回前就被关闭。

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