Manifest V3中document_start注入脚本过晚无法拦截早期XHR问题

开发一款Chrome扩展，核心功能为拦截页面响应体数据，处理生成实用统计信息后渲染到当前页面。
当前存在核心问题：请求拦截逻辑加载时机晚于页面核心请求的收发阶段，无法抓取这部分目标请求的数据。
问题复现可参考Chrome开发者工具网络面板截图：

• 仅显示XHR的截图中：绿色箭头标注需要抓取的目标请求，紫色括号覆盖范围为未被拦截的请求，黄色标注为已成功拦截的请求
• 同时展示XHR与JS文件的截图中：标识规则与上述一致，蓝色箭头标注了interceptor.js的实际执行时机

当前拦截器运行在匹配目标URL的内容脚本中，相关代码如下：

interceptor.js #

listenerFn = (event) => {
    console.log("Url:, ", event.target.responseURL);
    // 其余处理逻辑
}

(
    () => {
        var XHR = XMLHttpRequest.prototype;
        var send = XHR.send;
        XHR.send = function() {
            this.addEventListener('load', listenerFn)
            return send.apply(this, arguments);
        };
    }
)();

Manifest V3 配置（manifest.json） #

{
    "manifest_version": 3,
    "background": {
        "service_worker": "background.js"
    },
    "content_scripts": [
        {
          "matches": ["URL_OF_INTEREST.com/*"],
          "js": ["interceptor.js"],
          "run_at": "document_start"
        }
    ],
    "web_accessible_resources": [
        {
            "matches": ["<all_urls>"],
            "resources": ["interceptor.js"]
        }
    ],
    "permissions": [
        "scripting",
        "activeTab",
        "declarativeContent",
        "storage",
        "tabs"
    ],
    "host_permissions": [
        "*://*/*"
      ]
}

待确认的解决方向 #

目前梳理了3个可选解决方向，均不确定可行性：

1. 寻找更快注入拦截脚本的方案：当前已将run_at设置为document_start（官方标注的最早注入时机），不确定是否还有提速空间
2. 延迟页面所有请求，直到拦截脚本完全注入完成：不确定该方案是否可实现
3. 尝试使用chrome.WebRequest API实现拦截：已知该API无法直接获取响应体内容，不确定是否能满足需求

另有开发者提到该拦截逻辑不依赖页面内容，可迁移到background.js中运行，需要确认该方向是否可行。

首先明确现有实现的两个核心问题：

1. 配置的内容脚本默认运行在隔离世界（ISOLATED world），脚本里重写的XMLHttpRequest是隔离环境下的副本，和页面主世界（MAIN world）实际调用的XHR不是同一个对象，本身就存在拦截失效的概率
2. Manifest中声明的document_start内容脚本，注入时机仍然晚于页面初始HTML中同步触发的最早一批请求，这部分请求会直接漏过拦截

针对提到的三个方向逐一说明可行性：

• 方向1：没有提速空间。document_start是Chrome开放给内容脚本的官方最早注入时机，不存在更早的内容脚本注入配置
• 方向2：可以实现，但成本极高且容易破坏页面正常逻辑，不推荐
• 方向3：不可行。chrome.webRequest以及MV3新增的chrome.declarativeNetRequestAPI都无法直接获取响应体内容，完全不匹配需求
• 关于迁移到background.js的思路：方向可行，但Service Worker中无法直接访问页面的window对象、不能直接重写XHR/fetch，需要配合页面脚本注入实现，是目前MV3下解决早期请求拦截的标准方案，具体实现步骤如下：

1. 调整拦截脚本的注入目标世界
   拦截XHR/fetch的逻辑必须注入到页面主世界才能生效，不要放在默认的隔离世界。拦截脚本中需要同时hookXMLHttpRequest和window.fetch，避免遗漏fetch发起的请求。
2. 提前注册拦截脚本，保证最早注入时机
   不要仅依赖Manifest里的content_scripts声明注入，在background Service Worker中做两层保障：
   • 扩展首次安装、更新时，调用chrome.scripting.registerContentScripts注册永久生效的主世界拦截脚本，配置runAt: "document_start"、world: "MAIN"，匹配目标站点URL
   • 监听chrome.webNavigation.onBeforeNavigate事件，在页面刚开始导航、还未加载任何资源的时机，调用chrome.scripting.executeScript主动往对应标签页注入主世界拦截脚本，这个时机早于Manifest声明的内容脚本注入时间，能覆盖最早的页面启动请求
3. 打通数据传递链路
   主世界的拦截脚本无法直接调用Chrome扩展API，拦截到响应数据后，通过window.postMessage把数据发送给同页面运行在隔离世界的内容脚本，由内容脚本负责把数据传给background做统计处理，或者直接渲染到页面上即可。

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