1. 背景：API请求中的401错误与令牌刷新需求
在现代Web应用中，API请求的认证通常依赖于令牌（如JWT）。当客户端的令牌过期或无效时，服务器会返回401（Unauthorized）状态码。为了提供无缝的用户体验，前端应用通常会实现一个“响应拦截器”（response-interceptor）来捕获401错误，自动刷新令牌，并使用新令牌重试失败的请求。
然而，当多个并发请求同时遇到401错误时，如果不加以处理，可能会导致：
- 重复的令牌刷新请求：每个401请求都尝试发起一次令牌刷新，浪费服务器资源。
- 竞态条件：多个刷新请求返回的令牌可能互相覆盖，导致不一致的状态。
理想的解决方案是，当多个请求同时收到401时，只发起一次令牌刷新，并且所有等待的请求都共享这个刷新过程，并在新令牌可用后重试。
2. 初步尝试：利用Promise进行令牌刷新去重
为了解决上述问题，一种常见的策略是使用一个类字段（如awaitingPromise）来存储正在进行的令牌刷新Promise。当第一个请求遇到401并开始刷新令牌时，它会将刷新操作的Promise赋值给awaitingPromise。后续的并发请求如果也遇到401，则会等待awaitingPromise解析，获取新令牌，然后重试。
立即学习“Java免费学习笔记（深入）”；
以下是一个简化后的初始实现示例：
export class TokenFlushInterceptor {
private awaitingPromise: Promise | null = null; // 存储刷新令牌的Promise
private async retry(response: Response, requestOptions: RequestInit, token: string): Promise {
// 使用新令牌重试原请求
return fetch(response.url, {
...requestOptions,
headers: {
...requestOptions!.headers,
Authorization: `Bearer ${token}`,
},
});
}
public async intercept(response: Response, requestOptions?: RequestInit): Promise {
if (AUTH_RESPONSE_CODES.UNAUTHORIZED === response.status) {
if (this.awaitingPromise) {
// 如果已有刷新操作在进行，则等待其完成
const newToken = await this.awaitingPromise;
// 注意：这里原代码有将 awaitingPromise 置为 null 的操作，这可能导致问题
// this.awaitingPromise = null; // 潜在问题点
const retryRequest = await this.retry(response, requestOptions!, newToken);
// this.awaitingPromise = null; // 潜在问题点
return retryRequest;
}
// 如果没有刷新操作在进行，则发起新的刷新
const store = ReduxService.serverReduxStore; // 假设ReduxService可用
if (!store) {
return response; // 无法刷新，直接返回原响应
}
// 发起刷新令牌操作，并将其Promise保存
this.awaitingPromise = store.dispatch(flushToken) as Promise;
const newToken = await this.awaitingPromise;
// 注意：这里原代码有将 awaitingPromise 置为 null 的操作
// this.awaitingPromise = null; // 潜在问题点
const retryRequest = await this.retry(response, requestOptions!, newToken);
// this.awaitingPromise = null; // 潜在问题点
return retryRequest;
}
return response;
}
} 在上述代码中，this.awaitingPromise的意图是作为刷新令牌操作的“锁”。然而，原代码中多次将this.awaitingPromise设置为null的操作，引发了一个关键疑问：当一个请求（例如X请求）完成令牌刷新并设置this.awaitingPromise = null时，另一个同时等待的请求（例如Y请求）是否会因为this.awaitingPromise变为null而无法获取到新令牌？
3. 理解JavaScript的异步与单线程模型
要解答上述疑问，我们必须深入理解JavaScript的执行模型：
- 单线程：JavaScript在浏览器或Node.js环境中是单线程的。这意味着在任何给定时间点，只有一段代码在主线程上执行。
- 异步机制：虽然是单线程，但JavaScript通过事件循环（Event Loop）、回调函数、Promise和async/await等机制实现了非阻塞的异步操作。当遇到一个异步操作（如fetch请求或await一个Promise）时，JavaScript会将其委托给宿主环境（如浏览器API），然后继续执行主线程上的其他代码。当异步操作完成时，其回调或Promise的解决/拒绝会被放入任务队列（或微任务队列），等待主线程空闲时被执行。
- await关键字的行为：当await一个Promise时，当前async函数的执行会被暂停，并将该函数剩余的部分作为微任务放入微任务队列。主线程在此期间是不阻塞的，可以执行其他任务。当被await的Promise解决后，之前暂停的async函数会从暂停点恢复执行。
核心结论： 在JavaScript的单线程模型中，一旦代码进入一个同步执行块（例如一个if语句内部，直到遇到下一个await），该执行块中的变量值不会被“另一个线程”在中间意外修改。 具体到awaitingPromise的场景：
- 当一个请求（例如Y请求）执行到const newToken = await this.awaitingPromise;时，它会获取到this.awaitingPromise当前引用的那个Promise对象，并开始等待它。
- 即使在Y请求等待期间，其他代码（例如X请求的后续部分）将this.awaitingPromise变量设置为null，这并不会影响Y请求正在等待的那个Promise对象本身。Y请求仍然会等待它所引用的那个Promise对象解析，并获取其结果。
- 因此，Y请求不会因为this.awaitingPromise被设置为null而“丢失”正在等待的令牌刷新Promise。
用户提出的疑问：“awaitingPromise仍持有flushToken来自X请求，我们继续执行，但在X请求上下文中我们已经将awaitingPromise设置为null。那么，我们会在下面的代码段中得到null吗？” 答案是：不会。因为await操作是针对Promise对象本身的引用，而不是变量名。一旦await开始，它就“锁定”了那个Promise对象，即使变量被重新赋值或置空，正在等待的Promise也不会改变。
4. 健壮的令牌刷新拦截器实现
虽然JavaScript的单线程特性解决了“awaitingPromise在等待过程中被null掉”的误解，但原代码中过早地将this.awaitingPromise = null;的操作仍然是不健壮的。它应该在令牌刷新Promise真正完成（无论是成功还是失败）并且所有依赖它的请求都已处理完毕后，才被清除。
以下是一个更健壮的实现策略：
// 定义一个常量用于认证响应码
const AUTH_RESPONSE_CODES = {
UNAUTHORIZED: 401,
};
// 假设 ReduxService 和 flushToken 是可用的
// 例如：
// import { store } from './redux/store'; // 假设 Redux store 实例
// const ReduxService = { serverReduxStore: store };
// const flushToken = () => { /* 实际的刷新令牌dispatch操作，返回一个Promise */ return Promise.resolve("new_jwt_token"); };
export class TokenFlushInterceptor {
private awaitingPromise: Promise | null = null; // 存储刷新令牌的Promise
/**
* 重试原始请求，使用新的令牌
* @param response 原始的401响应
* @param requestOptions 原始请求的配置
* @param token 新的JWT令牌
* @returns 重试后的响应
*/
private async retry(response: Response, requestOptions: RequestInit, token: string): Promise {
const headers = {
...requestOptions?.headers,
Authorization: `Bearer ${token}`,
};
return fetch(response.url, {
...requestOptions,
headers,
});
}
/**
* 拦截器核心逻辑
* @param response 接收到的响应
* @param requestOptions 请求配置
* @returns 处理后的响应
*/
public async intercept(response: Response, requestOptions?: RequestInit): Promise {
// 如果不是401错误，则直接返回响应
if (AUTH_RESPONSE_CODES.UNAUTHORIZED !== response.status) {
return response;
}
let currentRefreshPromise: Promise;
// 检查是否已经有令牌刷新操作在进行
if (this.awaitingPromise) {
// 如果有，则所有后续的401请求都等待同一个刷新Promise
currentRefreshPromise = this.awaitingPromise;
} else {
// 如果没有，则发起一个新的令牌刷新操作
const store = ReduxService.serverReduxStore;
if (!store) {
console.error("Redux store not available for token refresh.");
throw new Error("Failed to refresh token: Redux store not initialized.");
}
// 发起刷新令牌的dispatch，并将其Promise保存到 awaitingPromise
// 确保 flushToken 返回一个 Promise
currentRefreshPromise = store.dispatch(flushToken) as Promise;
this.awaitingPromise = currentRefreshPromise;
// 关键：在刷新Promise完成（无论成功或失败）后，清除 awaitingPromise
// 这样确保只有当所有刷新逻辑都完成后，才能发起新的刷新 
