答案是：通过重写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调试稍微复杂一点。
评论（已关闭）
评论已关闭