Soybean Admin 并发请求下 Token 刷新机制问题分析与解决方案

2025-05-19 14:59:58作者：廉彬冶Miranda

问题背景

在 Soybean Admin 项目中，当系统初始化时同时发起多个 API 请求，如果此时访问令牌（Token）已过期，系统会触发令牌刷新机制。然而，当前实现存在一个关键缺陷：当多个并发请求同时检测到令牌过期时，系统仅会重新发起最先返回的那个请求，而其他请求则会被丢弃，导致页面数据不完整。

问题现象

具体表现为：在页面初始化阶段同时调用两个接口时，如果遇到令牌过期情况：

两个请求都会检测到令牌无效
系统执行令牌刷新操作
但刷新后仅重新发起其中一个请求
另一个请求的数据永远不会被获取
最终导致页面显示不完整

技术分析

当前实现机制

现有的令牌刷新逻辑采用了一种"先到先服务"的处理方式：

当请求失败并返回令牌过期错误时
系统会检查是否已经有刷新令牌的请求在进行中
如果没有，则发起新的令牌刷新请求
刷新完成后，仅重新发起触发刷新的那个原始请求

这种设计存在以下技术缺陷：

请求丢失：并发请求中只有最先返回的请求会被重新发起
数据不一致：页面可能只加载部分数据，导致UI显示不完整
用户体验差：用户需要手动刷新页面才能获取完整数据

根本原因

问题的核心在于令牌刷新后的请求重发机制没有考虑并发场景。系统没有维护一个待重发的请求队列，导致后续到达的过期请求无法被正确处理。

解决方案

优化思路

为了解决这个问题，我们需要重构令牌刷新机制，主要改进点包括：

请求队列管理：建立一个待重发请求的队列，记录所有因令牌过期而失败的请求
批量重发：在令牌刷新成功后，重新发起队列中的所有请求
并发控制：确保在令牌刷新过程中，新的请求能够正确加入队列

具体实现方案

创建请求缓存池：
- 使用一个数组或Map结构存储所有因令牌过期而失败的请求配置
- 每个请求应包含原始请求的配置、Promise的resolve和reject方法
改造刷新逻辑：
- 当检测到令牌过期时，不立即发起刷新请求
- 首先将当前请求加入缓存池
- 检查是否已有刷新流程在进行
- 如果没有，则发起令牌刷新请求
刷新后处理：
- 令牌刷新成功后，遍历缓存池中的所有请求
- 使用新令牌重新发起每个请求
- 清空缓存池
错误处理：
- 如果令牌刷新失败，应拒绝缓存池中所有请求的Promise
- 跳转到登录页面，要求用户重新认证

代码结构示例

// 请求缓存池
const requestPool = [];

// 拦截器处理
axios.interceptors.response.use(
  response => response,
  error => {
    if (error.response.status === 401) {
      // 将请求加入缓存池
      const retryOriginalRequest = new Promise(resolve => {
        requestPool.push({
          config: error.config,
          resolve
        });
      });
      
      // 如果没有刷新流程在进行，则发起刷新
      if (!isRefreshing) {
        isRefreshing = true;
        return refreshToken().then(() => {
          // 刷新成功后重发所有请求
          requestPool.forEach(({ config, resolve }) => {
            resolve(axios(config));
          });
          requestPool = [];
          isRefreshing = false;
        });
      }
      
      return retryOriginalRequest;
    }
    return Promise.reject(error);
  }
);