Chrome扩展URL参数注入：解决重定向历史记录重复问题

嘿，这个坑我之前踩过！你现在用chrome.tabs.update的方式相当于先让浏览器加载无参数的页面，再跳转到带参数的版本，自然会生成两条历史记录，返回的时候就陷入循环了。咱们换个更优雅的思路——在请求发送前直接修改URL，让浏览器只记录最终的目标页面，完美还原原生返回体验。

具体实现步骤 #

1. 更新Manifest权限 #

首先得给扩展加上拦截网络请求的权限，以Manifest V3为例，修改manifest.json：

{
  "manifest_version": 3,
  "name": "URL参数注入工具",
  "version": "1.0",
  "permissions": ["webRequest", "webRequestBlocking"],
  "host_permissions": ["https://search.com/*"],
  "background": {
    "service_worker": "background.js"
  }
}

如果是Manifest V2，把background字段改成"scripts": ["background.js"]即可，权限部分保持一致。

2. 替换后台脚本逻辑 #

把原来的chrome.tabs.onUpdated监听换成chrome.webRequest.onBeforeRequest——这是Chrome提供的网络请求拦截API，能在请求发出前直接修改目标URL：

chrome.webRequest.onBeforeRequest.addListener(
  (details) => {
    const currentUrl = new URL(details.url);
    // 检查是否已存在目标参数，避免重复处理
    if (!currentUrl.searchParams.has('new_param')) {
      currentUrl.searchParams.set('new_param', '1');
      // 返回修改后的URL，浏览器会直接请求这个地址
      return { redirectUrl: currentUrl.toString() };
    }
    // 已存在参数时，不做任何处理
    return {};
  },
  // 只拦截目标域名下的指定URL模式
  { urls: ["https://search.com/?*"] },
  // 必须声明blocking才能修改请求
  ["blocking"]
);

为什么这个方法有效？ #

这种方式是在浏览器发起请求的最早期阶段拦截修改，相当于直接告诉浏览器“去请求带参数的URL”，而不是先加载无参数页面再跳转。所以浏览器的历史记录里只会有一条带参数的页面记录，点击返回按钮时会直接回到上一个页面，完全不会触发重复重定向，和没有安装扩展时的体验一模一样。

额外注意点 #

• 确保host_permissions的范围足够覆盖你需要处理的URL，比如如果search.com还有其他路径需要处理，可以写成"https://search.com/*"。
• 用URLSearchParams操作参数比手动拼接字符串更安全，能避免参数冲突或者编码问题。

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