通过拦截器模式实现接口请求结果会话策略，核心是在全局 fetch 调用前注入逻辑，根据当前会话状态（如 token 过期）动态调整请求头或重试机制。具体做法是封装一个自定义的 request 函数，内部维护一个 isrefreshing 标志位和待处理队列 requestsqueue，当检测到 401 错误时触发刷新流程并挂起后续请求，直到新 token 获取成功后再依次执行队列中的请求。
如何拦截并处理单个请求的会话状态
在拦截单个请求时，主要关注的是请求发出前的预处理和响应后的错误处理。我们需要创建一个高阶函数来包装原生的 window.fetch，这样可以在不修改业务代码的情况下统一处理所有网络请求。对于会话策略而言，最关键的是在请求头中自动附加当前的认证信息，并在收到 401 状态码时识别出这是会话失效的信号。
const originalFetch = window.fetch;
window.fetch = async function(url, options = {}) {
// 1. 预处理：添加会话 Token
const token = sessionStorage.getItem('access_token');
if (token) {
options.headers = {
...options.headers,
'Authorization': `Bearer ${token}`
};
}
try {
const response = await originalFetch.apply(this, arguments);
// 2. 成功处理：更新会话时间戳
if (response.ok) {
sessionStorage.setItem('last_active', Date.now());
return response;
}
// 3. 失败处理：如果是 401，标记为需要刷新
if (response.status === 401) {
throw new Error('UNAUTHORIZED');
}
return response;
} catch (error) {
if (error.message === 'UNAUTHORIZED') {
// 进入刷新逻辑
return handleRefreshToken();
}
throw error;
}
};上述代码展示了基本的拦截结构。它首先从 sessionStorage 获取 Token 并注入到请求头中。如果请求成功，它会更新最后活跃时间，这可以用于实现空闲超时踢出功能。如果返回 401，则抛出特定错误以便上层统一捕获并进入刷新流程。这种单点拦截确保了所有请求都遵循相同的会话验证规则。
立即学习“Java免费学习笔记（深入）”；
如何处理并发请求下的 Token 刷新冲突
当多个请求同时遇到 401 错误时，如果每个请求都独立发起刷新 Token 的请求，会导致大量的重复请求甚至死循环。因此，必须引入“请求去重”和“排队等待”机制。我们使用一个布尔值 isRefreshing 来标识是否正在进行刷新操作，并使用一个数组 requestsQueue 来存储所有在刷新期间到达的失败请求回调。
let isRefreshing = false;
const requestsQueue = [];
function handleRefreshToken() {
return new Promise((resolve) => {
// 如果正在刷新，将当前请求加入队列
if (isRefreshing) {
requestsQueue.push(resolve);
return;
}
// 否则，开始刷新流程
isRefreshing = true;
refreshToken().then(newToken => {
// 刷新成功，更新本地存储
sessionStorage.setItem('access_token', newToken);
// 重置标志位
isRefreshing = false;
// 执行队列中的所有请求
requestsQueue.forEach(callback => callback(newToken));
requestsQueue.length = 0; // 清空队列
}).catch(() => {
// 刷新失败，清除会话并重定向
sessionStorage.clear();
window.location.href = '/login';
});
});
}
async function refreshToken() {
// 模拟刷新 Token 的 API 调用
const res = await fetch('/api/refresh', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ token: sessionStorage.getItem('refresh_token') })
});
const data = await res.json();
return data.access_token;
}在这个实现中，handleRefreshToken 函数充当了协调者的角色。当第一个 401 请求到来时，它设置 isRefreshing = true 并发起实际的刷新 API 调用。随后的 401 请求发现标志位为真，便不会再次发起刷新，而是将自身的恢复逻辑（即重新发起原请求）推入 requestsQueue。一旦刷新完成，队列中的所有回调会被依次执行，传入新的 Token，从而透明地完成重试。这种策略保证了在高并发场景下会话管理的正确性和效率。
基于请求队列满员条件的异常处理策略
在实际应用中，如果用户长时间未操作后突然进行大量批量操作，或者网络极差导致请求堆积，requestsQueue 可能会变得非常大。虽然 JavaScript 数组可以容纳很多元素，但无限增长可能导致内存问题或用户体验下降。因此，需要设定一个队列容量阈值，当超过该阈值时采取降级策略。
我们可以修改 handleRefreshToken 的逻辑，在将请求加入队列前检查长度。如果队列已满，直接拒绝该请求并提示用户“系统繁忙”或强制重新登录，而不是让其无限期等待。此外，还可以结合 AbortController 来取消那些等待过久的请求。例如，设置一个最大等待时间，如果刷新过程超过这个时间，队列中的剩余请求将被丢弃。这种基于队列状态的策略增强了系统的鲁棒性，防止因单一环节阻塞而导致整个应用假死。
