Chrome扩展从Manifest V2迁移至V3：捕获requestBody并修改响应

Manifest V3废弃了webRequestBlocking权限，而declarativeNetRequest无法直接读取和解析请求体内容，没法用它实现基于请求体键值对的条件判断。这里提供可行的迁移方案：

方案：用Service Worker的Fetch事件实现拦截与修改 #

这是最贴合原V2逻辑的替代方案，能完整实现“读取请求体→判断条件→返回自定义响应”的流程。

1. 配置Manifest V3清单文件 #

更新manifest.json，添加Service Worker和必要权限：

{
  "manifest_version": 3,
  "name": "GraphQL响应修改工具",
  "version": "1.0",
  "host_permissions": ["http://*/graphql"],
  "background": {
    "service_worker": "background.js"
  }
}

2. 编写Service Worker逻辑（background.js） #

替换原V2的webRequest.onBeforeRequest逻辑，用fetch事件实现相同功能：

// 自定义响应内容，替换成你的实际数据
const newResponse = { /* 例如：code: 200, data: { ... } */ };

self.addEventListener('fetch', (event) => {
  const req = event.request;
  // 过滤条件：POST请求、目标路径是/graphql、且为XHR请求
  if (req.method !== 'POST' || !req.url.endsWith('/graphql')) {
    return; // 不符合条件，直接放行
  }

  // 通过请求头判断是否为XMLHttpRequest（对应原V2的types过滤）
  const isXHR = req.headers.get('X-Requested-With') === 'XMLHttpRequest';
  if (!isXHR) {
    return;
  }

  // 克隆请求：Request的body只能读一次，克隆后不影响原请求放行
  const clonedReq = req.clone();

  event.respondWith(
    clonedReq.text().then(bodyText => {
      try {
        const body = JSON.parse(bodyText);
        // 判断请求体是否包含目标键值对
        if (body.key !== 'value') {
          return fetch(req); // 不符合，放行原请求
        }

        // 返回自定义响应
        return new Response(JSON.stringify(newResponse), {
          headers: { 'Content-Type': 'application/json;charset=utf-8' }
        });
      } catch (err) {
        // 请求体不是合法JSON，放行原请求
        return fetch(req);
      }
    }).catch(err => {
      // 读取请求体失败，放行原请求
      return fetch(req);
    })
  );
});

关键细节说明 #

• 请求克隆：必须克隆请求后再读取body，否则原请求的body会被消耗，导致不符合条件时无法正常发送请求。
• XHR判断：用X-Requested-With请求头识别XHR请求，和原V2的types: ['xmlhttprequest']效果一致。
• 容错处理：添加了解析失败、读取失败的兜底逻辑，避免拦截逻辑影响正常请求。

关于declarativeNetRequest的说明 #

declarativeNetRequest只能基于URL、请求头、方法等固定字段做匹配，不支持读取或解析请求体内容，所以没法满足你基于请求体键值对的判断需求，不适合这个场景。

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