首页 > web前端 > js教程 > 正文

JavaScript异步请求中401错误与令牌刷新:并发处理策略与实践

花韻仙語
发布: 2025-09-20 10:39:23
原创
981人浏览过

javascript异步请求中401错误与令牌刷新:并发处理策略与实践

本文深入探讨了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免费学习笔记(深入)”;

以下是一个简化后的初始实现示例:

Alkaid.art
Alkaid.art

专门为Phtoshop打造的AIGC绘画插件

Alkaid.art 153
查看详情 Alkaid.art
export class TokenFlushInterceptor {
    private awaitingPromise: Promise<string> | null = null; // 存储刷新令牌的Promise

    private async retry(response: Response, requestOptions: RequestInit, token: string): Promise<Response> {
        // 使用新令牌重试原请求
        return fetch(response.url, {
            ...requestOptions,
            headers: {
                ...requestOptions!.headers,
                Authorization: `Bearer ${token}`,
            },
        });
    }

    public async intercept(response: Response, requestOptions?: RequestInit): Promise<Response> {
        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<string>;
            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的场景:

  1. 当一个请求(例如Y请求)执行到const newToken = await this.awaitingPromise;时,它会获取到this.awaitingPromise当前引用的那个Promise对象,并开始等待它。
  2. 即使在Y请求等待期间,其他代码(例如X请求的后续部分)将this.awaitingPromise变量设置为null,这并不会影响Y请求正在等待的那个Promise对象本身。Y请求仍然会等待它所引用的那个Promise对象解析,并获取其结果。
  3. 因此,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<string> | null = null; // 存储刷新令牌的Promise

    /**
     * 重试原始请求,使用新的令牌
     * @param response 原始的401响应
     * @param requestOptions 原始请求的配置
     * @param token 新的JWT令牌
     * @returns 重试后的响应
     */
    private async retry(response: Response, requestOptions: RequestInit, token: string): Promise<Response> {
        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<Response> {
        // 如果不是401错误,则直接返回响应
        if (AUTH_RESPONSE_CODES.UNAUTHORIZED !== response.status) {
            return response;
        }

        let currentRefreshPromise: Promise<string>;

        // 检查是否已经有令牌刷新操作在进行
        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<string>
            currentRefreshPromise = store.dispatch(flushToken) as Promise<string>;
            this.awaitingPromise = currentRefreshPromise;

            // 关键:在刷新Promise完成(无论成功或失败)后,清除 awaitingPromise
            // 这样确保只有当所有刷新逻辑都完成后,才能发起新的刷新
登录后复制

以上就是JavaScript异步请求中401错误与令牌刷新:并发处理策略与实践的详细内容,更多请关注php中文网其它相关文章!

最佳 Windows 性能的顶级免费优化软件
最佳 Windows 性能的顶级免费优化软件

每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。

下载
来源:php中文网
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
最新问题
开源免费商场系统广告
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 举报中心 意见反馈 讲师合作 广告合作 最新更新 English
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送
PHP中文网APP
随时随地碎片化学习

Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号