JS拦截网络请求的几种方法

在前端开发中，**JS拦截网络请求**是实现统一错误处理、修改请求、数据模拟和性能优化的关键技术。主要有两种方法：一是通过“猴子补丁”重写XMLHttpRequest和fetch API，适用于应用内简单拦截和修改请求头等场景；二是通过Service Worker进行全局拦截，支持离线缓存、消息推送等高级功能，但需HTTPS环境且调试相对复杂。前者简单直接，后者功能强大但有作用域限制。本文将详细介绍这两种方法的具体实现，包括如何重写原生API、Service Worker的注册和使用，以及拦截不同请求方式（GET/POST等）的区别，并提醒拦截时可能遇到的坑和注意事项，助你掌握**JavaScript网络请求拦截**技术，提升开发效率和用户体验。

答案是：通过重写XMLHttpRequest和fetch API实现请求拦截，或使用Service Worker进行全局拦截。前者适用于应用内简单拦截，后者支持离线缓存与全局控制，但需HTTPS且调试复杂。

在JavaScript中，要实现网络请求拦截，核心手段无外乎两种：一是通过“猴子补丁”（Monkey Patching）的方式重写浏览器原生的XMLHttpRequest或fetch API；二则是利用更强大的Service Worker机制，在浏览器与网络之间建立一个可编程的代理层。这两种方法各有侧重，选择哪一个，往往取决于你的具体需求和对项目复杂度的接受程度。

解决方案

要具体实现请求拦截，我们可以这样操作：

1. 重写原生API（XMLHttpRequest & fetch）

这是最直接也最常见的做法，尤其适用于那些不需要Service Worker带来的离线能力，或者仅仅想在应用内部对请求做一些细微调整的场景。

对于XMLHttpRequest： 这个老伙计虽然有点过时，但在很多现有代码库里依然活跃。拦截它，通常意味着要重写它的open、send方法，甚至可能包括setRequestHeader。

(function() {
    const originalXHRopen = XMLHttpRequest.prototype.open;
    const originalXHRsend = XMLHttpRequest.prototype.send;

    XMLHttpRequest.prototype.open = function(method, url, async, user, password) {
        // 可以在这里获取或修改请求方法和URL
        console.log(`XHR open: ${method} ${url}`);
        this._method = method; // 存储方法和URL，以便send时使用
        this._url = url;
        originalXHRopen.apply(this, arguments);
    };

    XMLHttpRequest.prototype.send = function(body) {
        // 可以在这里检查或修改请求体
        console.log(`XHR send to ${this._url} with body:`, body);

        // 举例：修改请求头
        // this.setRequestHeader('X-Custom-Header', 'Intercepted!');

        // 可以在这里添加一个事件监听器来处理响应
        this.addEventListener('load', () => {
            if (this.readyState === 4) {
                console.log(`XHR response from ${this._url}:`, this.responseText);
                // 可以在这里统一处理响应数据，比如解密、格式化等
            }
        });

        originalXHRsend.apply(this, arguments);
    };
})();

这种方式的优点是简单直接，即时生效。但缺点也很明显，它只能作用于当前页面的JS执行环境，无法跨页面或在页面关闭后继续生效。而且，对同步XHR的拦截可能会带来性能问题，不过现在同步XHR已经很少用了。

对于fetch API：fetch是现代Web开发中进行网络请求的主流方式。拦截它比XHR稍微复杂一点，因为它基于Promise，并且Request和Response对象是不可变的。

(function() {
    const originalFetch = window.fetch;

    window.fetch = function(input, init) {
        // input 可以是 URL 字符串，也可以是 Request 对象
        // init 是请求的配置对象，如 method, headers, body 等

        let url = '';
        let method = 'GET';
        let headers = {};
        let body = null;

        if (typeof input === 'string') {
            url = input;
            method = (init && init.method) || 'GET';
            headers = (init && init.headers) || {};
            body = (init && init.body) || null;
        } else if (input instanceof Request) {
            // 如果 input 是 Request 对象，需要克隆它才能读取 body
            url = input.url;
            method = input.method;
            headers = Object.fromEntries(input.headers.entries()); // 转换为普通对象方便操作
            // Request.body 是一个 ReadableStream，只能读取一次
            // 所以如果需要修改或查看 body，必须克隆 Request
            if (input.bodyUsed) {
                // 如果 body 已经被使用过，这里就无法再次读取了
                // 通常在拦截器里，input.bodyUsed 应该为 false
                console.warn('Request body already used.');
            } else {
                // 克隆请求，以便后续可以再次使用原始请求体
                const clonedRequest = input.clone();
                // 异步读取 body
                clonedRequest.text().then(text => {
                    body = text;
                    console.log(`Fetch request body for ${url}:`, body);
                });
            }
        }

        console.log(`Fetch request: ${method} ${url}`);
        // 可以在这里修改 init 对象，比如添加统一的认证头
        const newInit = { ...init };
        newInit.headers = {
            ...newInit.headers,
            'X-Intercepted-By': 'MyAwesomeInterceptor'
        };

        return originalFetch(input, newInit)
            .then(response => {
                // 可以在这里处理响应，比如统一的错误码处理
                if (!response.ok) {
                    console.error(`Fetch error for ${url}: ${response.status}`);
                }
                // 响应对象也是不可变的，如果需要修改响应，需要克隆或创建新的Response
                const clonedResponse = response.clone();
                clonedResponse.json().then(data => {
                    console.log(`Fetch response data for ${url}:`, data);
                }).catch(e => {
                    // 某些响应可能不是JSON，比如图片或文本
                    console.log(`Fetch response text for ${url}:`, e);
                });
                return response; // 返回原始响应或修改后的响应
            })
            .catch(error => {
                console.error(`Fetch network error for ${url}:`, error);
                throw error; // 抛出错误以便调用链继续处理
            });
    };
})();

fetch的拦截更现代，但因为Request和Response对象的不可变性，如果你需要读取或修改请求体/响应体，就得用到clone()，这会稍微增加一些代码的复杂性。

2. 使用Service Worker

Service Worker是独立于主线程的脚本，它能拦截页面发出的所有网络请求（在它的作用域内），并且可以实现离线缓存、消息推送等高级功能。这是实现真正意义上“全局”请求拦截的强大工具。

注册Service Worker： 在主页面JS中：

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js')
        .then(registration => {
            console.log('Service Worker registered with scope:', registration.scope);
        })
        .catch(error => {
            console.error('Service Worker registration failed:', error);
        });
}

在service-worker.js中： 这是核心的拦截逻辑。

// service-worker.js
self.addEventListener('install', (event) => {
    console.log('Service Worker installing...');
    self.skipWaiting(); // 强制新的 Service Worker 立即激活
});

self.addEventListener('activate', (event) => {
    console.log('Service Worker activating...');
    event.waitUntil(clients.claim()); // 确保 Service Worker 控制所有客户端
});

self.addEventListener('fetch', (event) => {
    // 拦截所有网络请求
    const request = event.request;
    console.log(`Service Worker intercepted fetch for: ${request.url}`);

    // 示例1：修改请求头
    const newHeaders = new Headers(request.headers);
    newHeaders.set('X-Service-Worker-Intercepted', 'true');
    const modifiedRequest = new Request(request, { headers: newHeaders });

    // 示例2：模拟响应（Mocking）
    if (request.url.includes('/api/mockdata')) {
        const mockResponse = new Response(JSON.stringify({
            message: 'This is mocked data from Service Worker!'
        }), {
            headers: { 'Content-Type': 'application/json' }
        });
        event.respondWith(mockResponse);
        return; // 阻止默认行为
    }

    // 示例3：缓存策略 - 优先从缓存获取，否则从网络获取并缓存
    event.respondWith(
        caches.match(request).then((response) => {
            if (response) {
                console.log(`Serving from cache: ${request.url}`);
                return response;
            }
            console.log(`Fetching from network: ${request.url}`);
            return fetch(modifiedRequest).then((networkResponse) => {
                // 检查响应是否有效，例如状态码200
                if (!networkResponse || networkResponse.status !== 200 || networkResponse.type !== 'basic') {
                    return networkResponse;
                }
                const responseToCache = networkResponse.clone();
                caches.open('my-app-cache').then((cache) => {
                    cache.put(request, responseToCache);
                });
                return networkResponse;
            });
        }).catch(error => {
            console.error('Service Worker fetch error:', error);
            // 可以在这里返回一个离线页面或错误响应
            return new Response('Offline content or error page', { status: 503, headers: { 'Content-Type': 'text/plain' } });
        })
    );
});

Service Worker的强大之处在于它运行在一个独立的线程中，不会阻塞主线程，并且可以在页面关闭后继续工作（例如处理推送通知）。它还能实现复杂的缓存策略，让你的应用具备真正的离线能力。不过，它的缺点是需要HTTPS环境，调试起来也相对复杂一些，而且有作用域限制。

为什么我们需要拦截网络请求？

嗯，这个问题问得好。作为开发者，我们为什么非要给网络请求“找麻烦”呢？其实，拦截网络请求并非多此一举，它在许多实际场景中都扮演着关键角色。

首先，统一的错误处理和日志记录。想象一下，你的应用有几十甚至上百个API请求，如果每个请求都单独处理错误，那代码会变得异常臃肿且难以维护。通过拦截，我们可以在一个中心点捕获所有请求的响应，无论是成功还是失败，然后统一进行错误提示、数据上报或日志记录。这就像给所有的快递都加了一个中转站，确保它们无论送达与否，都有记录可查，并且能及时处理异常情况。

其次，请求的修改与重试。有时候，我们需要在请求发送前动态地添加一些公共参数，比如认证Token、设备信息，或者在某些网络不稳定的情况下自动重试失败的请求。拦截器能很方便地实现这些需求，避免在每个业务逻辑中重复编写这些“样板代码”。

再者，数据模拟（Mocking）。在前端开发中，我们经常需要等待后端API开发完成。有了请求拦截，前端可以完全脱离后端，通过拦截特定的请求并返回预设的模拟数据来独立进行开发和测试。这极大地提高了开发效率，也方便了单元测试和集成测试。

最后，性能优化与缓存策略。Service Worker的拦截能力，让我们可以实现复杂的离线缓存策略，比如“缓存优先”、“网络优先”或“竞速”模式。这不仅能让用户在网络不佳甚至离线时也能访问部分内容，还能显著提升页面加载速度，改善用户体验。

拦截不同请求方式（GET/POST等）有什么区别？

从拦截机制本身来看，无论是通过猴子补丁还是Service Worker，拦截GET、POST、PUT、DELETE等不同HTTP方法并没有本质上的区别。拦截器捕获的是一个网络请求的“事件”或者“对象”，这个对象包含了请求的所有信息，比如URL、方法、请求头、请求体等。

真正的区别在于，当你处理这些被拦截的请求时，你可能需要根据HTTP方法的不同，采取不同的处理逻辑：

• GET请求： GET请求的数据通常通过URL参数（query string）传递。在拦截器中，如果你需要查看或修改GET请求的参数，你需要解析request.url来获取这些参数。比如，new URL(request.url).searchParams可以帮助你获取URL中的查询参数。因为GET请求通常没有请求体，所以你不会像处理POST请求那样去关心request.body。
• POST/PUT/PATCH请求： 这些请求通常会带有请求体（request body），用来发送数据到服务器。在拦截器中，如果你需要读取或修改请求体，就需要特别注意。对于fetch API，request.body是一个ReadableStream，它只能被读取一次。这意味着如果你读取了它，原始的request对象就不能再被fetch函数使用了。因此，在这种情况下，你通常需要先克隆request对象（request.clone()），然后从克隆体中读取body，再根据需要创建一个新的Request对象来继续发送，或者直接返回一个模拟响应。

简单来说，拦截器会给你一个统一的“请求对象”，但这个对象内部的具体内容（特别是请求体）会因为HTTP方法的不同而有差异，你需要根据这些差异来编写你的处理逻辑。

拦截网络请求时可能遇到的坑和注意事项

在尝试拦截网络请求时，虽然它功能强大，但有时也会让人感到“头疼”，遇到一些意想不到的挑战。

一个常见的“坑”是fetch API中Request和Response对象的不可变性。当你拦截到一个Request对象，如果你想读取它的body（比如一个POST请求的JSON数据），或者修改响应，你不能直接操作原始对象。body是一个流，一旦被读取，就“消耗”掉了，原始请求就不能再被发送。所以，你必须使用request.clone()来复制一份请求，从副本中读取body，然后用原始请求（或基于原始请求修改的新请求）继续后续操作。同样，如果你想修改一个响应，也需要先response.clone()，然后基于克隆的响应创建一个新的Response对象返回。这在代码逻辑上会增加一些复杂度。

其次，是拦截逻辑的异步性。无论是fetch还是Service Worker，它们的拦截和处理过程都是异步的。这意味着你需要熟练掌握Promise和async/await。如果你的拦截逻辑中有阻塞操作，或者没有正确处理Promise链，很容易导致请求挂起、响应延迟，甚至整个页面卡死。调试这种异步问题，有时会比同步代码更具挑战性。

再来，多重拦截或“猴子补丁”的顺序问题。如果你的应用中引入了多个库或脚本，它们都尝试对XMLHttpRequest或fetch进行“猴子补丁”式的拦截，那么它们的执行顺序就变得至关重要。谁最后对原生API进行了重写，谁的拦截器就可能生效。这可能导致预期的拦截行为被覆盖，或者产生难以追踪的bug。在设计这类功能时，最好能有一个统一的拦截管理机制，避免各自为政。

最后，Service Worker虽然强大，但它也有自己的作用域限制和生命周期管理。一个Service Worker只能拦截其注册路径下的请求。例如，如果你的Service Worker注册在/，它可以拦截所有请求；但如果注册在/js/，它就只能拦截/js/路径下的请求。此外，Service Worker的更新、激活、废弃等生命周期管理也需要你额外关注，不当的操作可能导致老版本缓存无法清除，或者新版本Service Worker无法立即生效，从而影响用户体验。同时，Service Worker的调试也需要借助浏览器开发者工具的“Application”面板，比普通的JS调试稍微复杂一点。

终于介绍完啦！小伙伴们，这篇关于《JS拦截网络请求的几种方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！