本文深入探讨了JavaScript中处理并发异步请求时遇到的401未授权错误及令牌刷新机制。我们分析了在response-interceptor中如何利用Promise来避免重复的令牌刷新操作，并详细解释了JavaScript单线程异步模型的行为，澄清了对并发状态管理的常见误解。通过提供一个健壮的解决方案，文章旨在帮助开发者构建更高效、可靠的认证拦截器。
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 // 这样确保只有当所有刷新逻辑都完成后，才能发起新的刷新
以上就是JavaScript异步请求中401错误与令牌刷新：并发处理策略与实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1521024.html
微信扫一扫 
支付宝扫一扫 
