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

问题背景

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

问题现象

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

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

技术分析

当前实现机制

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

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

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

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

根本原因

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

解决方案

优化思路

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

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

具体实现方案

1. 创建请求缓存池：

   • 使用一个数组或Map结构存储所有因令牌过期而失败的请求配置
   • 每个请求应包含原始请求的配置、Promise的resolve和reject方法

2. 改造刷新逻辑：

   • 当检测到令牌过期时，不立即发起刷新请求
   • 首先将当前请求加入缓存池
   • 检查是否已有刷新流程在进行
   • 如果没有，则发起令牌刷新请求

3. 刷新后处理：

   • 令牌刷新成功后，遍历缓存池中的所有请求
   • 使用新令牌重新发起每个请求
   • 清空缓存池

4. 错误处理：

   • 如果令牌刷新失败，应拒绝缓存池中所有请求的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);
  }
);

实施建议

1. 逐步迁移：对于已上线的系统，建议先在测试环境验证新机制
2. 监控指标：添加对并发请求重发次数的监控，确保系统稳定性
3. 性能考量：对于高并发场景，考虑设置请求池大小限制
4. 用户体验：可以添加全局加载提示，告知用户系统正在更新认证信息

总结

Soybean Admin 的令牌刷新机制在并发场景下的问题，本质上是一个经典的竞态条件问题。通过引入请求队列管理和批量重发机制，我们能够确保所有因令牌过期而失败的请求都能在令牌更新后得到正确处理。这种改进不仅解决了数据丢失的问题，也提升了系统的健壮性和用户体验。

对于前端开发者而言，正确处理认证流程中的并发场景是构建可靠管理系统的关键。这种解决方案的思路也可以应用于其他需要处理类似竞态条件的场景，如表单重复提交防护、批量操作处理等。