使用declarativeNetRequest.updateDynamicRules拦截请求后能否执行操作及统计拦截数方法

declarativeNetRequest是浏览器层面的声明式API，拦截请求的逻辑由浏览器直接执行，扩展的JS代码不会收到拦截事件的回调，因此无法直接在拦截后触发后续操作。

如果需要基于拦截行为执行额外逻辑，可通过间接方式实现：

• 若业务允许，将规则的action设为allow而非block，同时通过modifyHeaders action给请求添加自定义请求头，再用chrome.webRequest.onBeforeSendHeaders监听带有该自定义头的请求，在回调中执行后续操作。
• 对于必须拦截的请求，可定期调用chrome.declarativeNetRequest.getMatchedRules()查询匹配记录，但这种方式无法实时触发操作，仅适合批量统计类场景。

由于declarativeNetRequest没有内置的拦截计数API，可通过以下两种可靠方式实现：

方式1：规则匹配事件+本地存储计数 #

1. 在manifest.json中声明declarativeNetRequestWithHostAccess权限（需与规则权限范围匹配）。
2. 给目标拦截规则设置唯一id，监听chrome.declarativeNetRequest.onRuleMatched事件，每次触发时判断匹配的规则ID是否为目标拦截规则，再更新本地存储中的计数。
3. 示例代码：

   // 初始化监听
   chrome.declarativeNetRequest.onRuleMatched.addListener((details) => {
     // 替换为你的拦截规则ID
     const TARGET_BLOCK_RULE_ID = 123;
     if (details.ruleId === TARGET_BLOCK_RULE_ID) {
       chrome.storage.local.get('blockCount', (result) => {
         const newCount = (result.blockCount ?? 0) + 1;
         chrome.storage.local.set({ blockCount: newCount });
       });
     }
   });
   

   注意：onRuleMatched会在所有规则匹配时触发（包括allow类规则），必须通过ruleId过滤目标拦截规则。

方式2：结合webRequest监听（仅适用于非强制拦截场景） #

如果业务允许将拦截改为“允许请求+标记”，可给规则添加modifyHeaders action，给请求添加自定义头（比如X-Extension-Blocked: true），然后用chrome.webRequest.onCompleted监听带有该头的请求，每次触发时计数加1。这种方式适合需要同时处理请求内容的场景，但不适用于必须拦截的请求。

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