如何用Tampermonkey脚本拦截特定网络请求

本文详解如何利用 Tampermonkey 的 GM_webRequest API 或 @webRequest 元指令，在 YouTube 等网站中精准拦截（如搜索建议）特定 GET 请求，避免无效的 fetch/XHR 替换方案。

先说结论：想在 YouTube 这类网站上，用 Tampermonkey 的用户脚本精准拦截掉搜索建议这种特定 GET 请求，真正靠谱的方案，是用它原生支持的网络层拦截机制——也就是 GM_webRequest API 或者 @webRequest 元指令。那些试图去劫持 fetch 或者重写 XMLHttpRequest.prototype.send 的老路子，说实话，基本上走不通。

很多时候，我们会遇到一个很头疼的情况：浏览器自动化和隐私优化的场景下，光是禁掉前端功能——比如清个 Cookie、关个设置——根本挡不住 YouTube 搜索框背后那些自动触发的请求。它们会悄悄地向 https://suggestqueries-clients6.youtube.com/complete/search... 这类地址发请求。如果用户脚本打算用劫持 fetch 或者重写 XMLHttpRequest.prototype.send 的方式来拦截，很容易因为执行时机太晚、请求已经被框架封装、或者碰上了跨域策略的限制而失效。

而这两个原生方案则完全不同。它们工作在整个浏览器网络栈的最底层，在请求真正发出之前，就已经完成了匹配和阻断。可靠性和侵入性都要好得多。

推荐方案一：使用 GM_webRequest（动态可控）

// ==UserScript==
// @name         YouTube URL Blocker
// @namespace    http://tampermonkey.net/
// @version      0.2
// @description  阻止 YouTube 搜索建议请求（底层拦截）
// @author       me
// @match        https://www.youtube.com/*
// @grant        GM_webRequest
// ==/UserScript==

(function() {
    'use strict';
    // 支持通配符匹配：* 表示任意字符（含路径参数）
    const blockedSelector = 'https://suggestqueries-clients6.youtube.com/complete/search*';
    GM_webRequest([
        { selector: blockedSelector, action: 'cancel' }
    ], (info, message, details) => {
        console.info('[YouTube Blocker] 已拦截搜索建议请求:', info.url);
    });
})();

注意事项：

• selector 必须为完整 URL 或含 * 的通配模式（如 https://example.com/api/*），不支持正则表达式；
• action: 'cancel' 会彻底终止请求，返回空响应（状态码 0，无网络错误提示）；
• 回调函数仅在请求被拦截时触发，可用于日志调试，但不影响拦截行为本身（即即使回调未定义，拦截仍生效）；
• 该 API 需显式声明 @grant GM_webRequest，且仅适用于 Chromium 内核浏览器（Chrome、Edge、Bra ve 等）及新版 Firefox（需启用 privacy.webRequest.allowHttpFiltering）。

推荐方案二：使用 @webRequest 元指令（启动即生效）

// ==UserScript==
// @name         YouTube URL Blocker (Static)
// @namespace    http://tampermonkey.net/
// @version      0.2
// @description  启动时立即拦截搜索建议请求（零延迟）
// @author       me
// @match        https://www.youtube.com/*
// @webRequest   {"selector":"https://suggestqueries-clients6.youtube.com/complete/search*","action":"cancel"}
// ==/UserScript==

// 此处可留空，或添加其他 DOM 操作逻辑（如隐藏搜索建议面板）

这个方式的优势在于，规则在用户脚本被加载之前就已经注册到浏览器的网络监听器里了，完全规避了竞态问题。非常适合那种对时效性要求极高的拦截场景。语法很简洁，不需要 Ja vaScript 的执行上下文，灵活性上比 GM_webRequest 要差一点——没法在运行时动态修改规则。

为什么传统方法会失败？

• fetch 重写：YouTube 大量的请求是通过内部封装的请求工具（比如 yt.networking）发出的，并不是直接调用全局的 fetch 函数；
• XMLHttpRequest.prototype.send 劫持：现代框架通常会通过 new XMLHttpRequest() 实例化后直接调用 send()，但 _url 这个属性其实并不存在，需要手动去 patch open() 方法才能拿到真正的 URL。更麻烦的是，一部分请求是由 Service Worker 或者内置模块发起的，直接绕过了原型链；
• beforesendheaders 事件：这里又有一个容易踩的坑——这个事件并非标准 Web API，Tampermonkey 根本不提供这个事件，属于一种常见的误解。

最终验证建议

1. 打开 YouTube → 点击搜索框 → 打开 DevTools → 切换到 Network 标签页；
2. 在 Filter 里输入 suggestqueries，确认相关的请求已经彻底消失（而不是显示 cancelled 或者报错）；
3. 观察搜索建议的下拉列表，是不是变成了空白，或者不再自动弹出——这就说明拦截成功了。

总而言之，在当前的 Tampermonkey 生态里，GM_webRequest 和 @webRequest 是拦截特定请求的唯一可靠方案。合理地对通配符进行选择，正确配置好 @grant 或元指令，再结合 Network 面板来做一次验证，就能稳定地实现隐私增强和性能优化的目标了。