MV3扩展使用declarativeNetRequest可否匹配POST请求体重写响应

1. redirect 搭配 dataUri 返回自定义响应的方案合理性 #

• 这是MV3架构下替换接口响应的通用合规实现，不存在过度设计。
• MV3 正式废弃了 MV2 时代 webRequest API 阻塞式修改响应体的能力，官方推荐的响应替换路径里，DNR 重定向是性能、权限开销最优的选择：
  • 规则匹配完全由浏览器内核原生执行，不需要扩展 Service Worker 常驻监听请求，内存占用极低，也不会触发高危权限告警。
  • 你当前用的 dataUri 方案不需要在扩展包里预置静态文件，适合用户自定义输入响应内容的动态场景，是同类Mock类扩展（比如接口调试、演示数据注入类工具）的普遍实现。
• 该方案唯一的限制是 dataUri 单地址长度上限约为2MB，如果后续需要注入更大体积的仿真数据，把重定向目标换成扩展内置的资源路径即可，核心逻辑不需要调整。
• 你当前写的规则示例没有兼容性问题，可以直接用：

{
 "id": idVariable,
 "priority": 1,
 "action" : { "type" : "redirect", "redirect": {
   "url": `data:application/json;charset=utf-8;base64,${btoa(remix.response)}`
 }},
 "condition" : {
   "urlFilter": endpointVariable
 }
}

如果要匹配POST请求，只需要在condition里补加"requestMethods": ["POST"]字段即可。

2. DNR 对POST请求体的匹配能力说明 #

• 目前所有正式版Chrome的DNR能力完全不支持获取、匹配请求体内容，这个是API设计层面的硬性限制，没有配置项可以绕过。
• DNR的核心设计原则就是最小化扩展能接触到的请求数据，避免扩展窃取请求中携带的用户敏感信息（比如密码、表单提交内容、身份凭证），因此规则匹配维度仅覆盖URL、请求方法、请求头、资源类型、关联tab、域名这些非敏感字段，从来没有开放过请求体的匹配权限。
• 针对你提到的单接口完全靠POST body区分报表类型的场景，可行的落地方案只有一类：
  • 先用DNR规则把目标路径的所有请求重定向到扩展自身的轻量转发页
  • 在转发逻辑中读取原始请求的body载荷，完成自定义规则匹配
  • 根据匹配结果返回对应的仿真模拟数据
• 不要尝试用webRequestAPI监听请求体做匹配，MV3下webRequest的监听是非阻塞的，等你拿到请求体内容的时候，原始请求已经发到服务器了，根本做不到响应拦截替换。

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