答案是：通过重写XMLHttpRequest和fetch API实现请求拦截，或使用Service Worker进行全局拦截。前者适用于应用内简单拦截，后者支持离线缓存与全局控制，但需HTTPS且调试复杂。
在JavaScript中，要实现网络请求拦截，核心手段无外乎两种：一是通过“猴子补丁”（Monkey Patching）的方式重写浏览器原生的
XMLHttpRequest或
fetchAPI；二则是利用更强大的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调试稍微复杂一点。
