Chrome扩展中PDF文本提取场景下内容脚本向后台脚本返回消息出现Undefined响应的问题

我来帮你一步步排查这个问题——从你的代码和现象来看，最可能的原因和对应的解决方案如下：

1. 最可能的元凶：消息内容超出Chrome的大小限制 #

Chrome扩展的sendMessage/sendResponse机制有默认的内容大小限制（通常在1MB左右）。你的PDF提取场景返回的文本大概率长度超过了这个阈值，导致浏览器直接丢弃了响应，后台自然就收到了undefined；而复制粘贴的场景文本很短，所以能正常传递。

验证方法：在PDF提取的内容脚本里，临时把sendResponse({ result: text })改成sendResponse({ result: "测试短文本" })，如果后台能正常收到这个短字符串，就坐实了是大小问题。

解决方案：
如果是大小限制导致的，你可以换一种方式传递数据：

• 用chrome.storage.local临时中转：内容脚本把长文本存入本地存储，再把存储的key发给后台，后台通过key读取内容：
  内容脚本修改：

  chrome.runtime.onMessage.addListener(async (message, sender, sendResponse) => {
    if (message.action === 'EXTRACT_TAB_DATA') {
      // ... 你的PDF提取逻辑
      const tempKey = `pdf_temp_${Date.now()}`;
      await chrome.storage.local.set({ [tempKey]: text });
      sendResponse({ tempKey });
      return true;
    }
    return true;
  });
  

  后台脚本修改：

  const response = await chrome.tabs.sendMessage(tab.id, { action: 'EXTRACT_TAB_DATA', url });
  if (response.tempKey) {
    const { [response.tempKey]: extractedText } = await chrome.storage.local.get(response.tempKey);
    console.log(extractedText);
    // 用完及时清理临时存储
    await chrome.storage.local.remove(response.tempKey);
  }
  

• 用长连接分块传递：通过chrome.runtime.connect建立持久端口，把长文本拆成小块分批发送，这种方式的大小限制宽松很多。

2. Async回调与sendResponse的配合优化 #

虽然你的代码里已经return true来保持消息通道打开，但用async函数作为onMessage回调时，Chrome的处理逻辑有更简洁的写法，也能避免潜在的冲突：

// 内容脚本修改后的回调
chrome.runtime.onMessage.addListener(async (message, sender) => {
  if (message.action === 'EXTRACT_TAB_DATA') {
    // ... 你的PDF提取逻辑
    return { result: text }; // 直接返回响应，无需调用sendResponse
  }
  return {};
});

这种写法下，async函数返回的Promise会被Chrome自动处理为响应，不需要额外return true，逻辑更清晰。

3. 额外排查：PDF页面的内容脚本注入上下文 #

Chrome内置的PDF查看器可能会在子frame中渲染内容，如果你没在manifest的content_scripts里设置all_frames: true，内容脚本可能只注入到主frame，偶尔会导致消息传递异常。你可以在manifest里补充这个配置：

"content_scripts": [
  {
    "matches": ["http://*/*", "https://*/*"],
    "js": ["src/contentScript/index.ts-loader.js"],
    "all_frames": true // 新增这一行
  }
]

快速验证步骤 #

1. 先测试短文本响应是否能正常到达后台，确认是否是大小问题；
2. 如果是大小问题，改用本地存储中转的方式；
3. 同时优化async回调的写法，避免潜在的逻辑冲突。

内容来源于stack exchange