Chrome扩展MV3中如何替代onBeforeSendHeaders的blocking拦截逻辑

一、核心替代方案：在Service Worker中使用chrome.webRequest保留自定义逻辑 #

MV3并未完全移除chrome.webRequest的blocking能力，只是将其限制在Service Worker中运行，正确配置权限后即可沿用原有自定义逻辑：

1. 配置manifest.json #

声明必要权限与Service Worker类型：

{
  "manifest_version": 3,
  "background": {
    "service_worker": "background.js"
  },
  "permissions": ["webRequest", "webRequestBlocking", "tabs"],
  "host_permissions": ["<你的目标URL范围>"] // 例如["*://*.example.com/*"]或["<all_urls>"]
}

2. 在Service Worker中重写拦截逻辑 #

沿用原有逻辑框架，修正细节适配MV3：

chrome.webRequest.onBeforeSendHeaders.addListener(
  (details) => {
    // 处理Purpose:prefetch请求（修正原代码的判断逻辑）
    const purposeHeader = details.requestHeaders.find(header => header.name.toLowerCase() === 'purpose');
    if (purposeHeader && purposeHeader.value === 'prefetch') {
      return {};
    }

    // 自定义条件判断（替换为你的原有逻辑）
    const condition = /* 你的条件判断代码 */;
    
    if (condition) {
      // 执行标签页更新操作
      chrome.tabs.update(details.tabId, { /* 你的params参数 */ });
      return { cancel: true };
    }

    return { cancel: false };
  },
  { urls: ["<通过WebSocket获取的URL列表>"], types: ['main_frame'] },
  ['blocking', 'requestHeaders']
);

二、declarative_net_request的局限性说明 #

declarative_net_request仅适合静态/简单规则的批量拦截，无法承载复杂动态逻辑：

• 动态规则有数量限制（默认150条，最高可申请至5000条）
• 无法嵌入依赖实时数据、多分支判断的自定义代码
• 无法在规则中执行chrome.tabs.update这类API操作

若你的逻辑依赖实时计算、动态数据（比如WebSocket获取的URL列表），使用chrome.webRequest的blocking模式是更直接的替代方案。

三、注意事项 #

• Service Worker会自动休眠，若需维持WebSocket连接，需确保连接活跃以唤醒Worker
• webRequestBlocking权限必须在manifest中明确声明，且host_permissions需覆盖所有需要拦截的URL
• 避免在blocking回调中执行耗时操作，防止影响请求响应速度

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