Soybean Admin 项目中并发请求刷新 Token 的问题分析与解决方案
2025-05-19 07:00:16作者:宣聪麟
问题背景
在 Soybean Admin 项目中,当页面初始化时同时发起多个 API 请求,如果此时访问令牌(Token)已过期,系统会触发令牌刷新机制。然而,当前的实现存在一个关键问题:当多个并发请求同时检测到令牌过期时,系统仅会重新发起最先返回的那个请求,而其他请求则会被丢弃,导致页面数据不完整。
问题分析
这种问题通常出现在前端应用中,当多个异步请求同时进行时,它们各自独立检测令牌的有效性。当第一个请求发现令牌过期并触发刷新流程后,其他并行请求可能已经进入了错误处理流程,而没有被纳入令牌刷新后的重试机制中。
从技术实现角度看,这涉及到以下几个关键点:
- 令牌刷新机制:当前实现可能采用了简单的单例模式,只处理第一个触发的刷新请求
- 请求队列管理:缺乏对并发请求的统一管理和协调
- 错误处理流程:没有将并行请求的错误统一收集并纳入重试机制
解决方案
要解决这个问题,我们需要重构令牌刷新和请求重试的流程。以下是几种可行的技术方案:
方案一:请求队列与令牌锁
- 当检测到令牌过期时,先设置一个"刷新中"的状态标志
- 将所有后续请求加入等待队列
- 令牌刷新完成后,统一重试队列中的所有请求
- 清除"刷新中"标志
这种方案可以有效避免重复刷新令牌,同时确保所有请求都能得到正确处理。
方案二:Axios 拦截器优化
对于使用 Axios 的项目,可以在请求拦截器中实现更智能的处理:
let isRefreshing = false;
let failedQueue = [];
const processQueue = (error, token = null) => {
failedQueue.forEach(prom => {
if (error) {
prom.reject(error);
} else {
prom.resolve(token);
}
});
failedQueue = [];
};
axios.interceptors.response.use(
response => response,
error => {
const originalRequest = error.config;
if (error.response.status === 401 && !originalRequest._retry) {
if (isRefreshing) {
return new Promise((resolve, reject) => {
failedQueue.push({resolve, reject});
}).then(token => {
originalRequest.headers['Authorization'] = 'Bearer ' + token;
return axios(originalRequest);
}).catch(err => {
return Promise.reject(err);
});
}
originalRequest._retry = true;
isRefreshing = true;
return new Promise((resolve, reject) => {
refreshToken().then(({token}) => {
setNewToken(token);
originalRequest.headers['Authorization'] = 'Bearer ' + token;
processQueue(null, token);
resolve(axios(originalRequest));
}).catch(err => {
processQueue(err, null);
reject(err);
}).finally(() => {
isRefreshing = false;
});
});
}
return Promise.reject(error);
}
);
方案三:全局状态管理
对于使用 Vuex 或 Pinia 的项目,可以将令牌刷新状态纳入全局状态管理:
- 在 store 中维护
isRefreshing状态和pendingRequests队列 - 任何组件或服务在发起请求前检查刷新状态
- 如果刷新正在进行,将请求加入队列
- 刷新完成后,派发一个全局事件通知所有等待的请求
实施建议
在实际项目中实施时,建议考虑以下几点:
- 错误边界处理:为队列中的请求设置合理的超时时间,避免无限等待
- 用户体验:在等待令牌刷新期间,可以显示全局加载状态
- 日志记录:记录令牌刷新和请求重试的详细日志,便于问题排查
- 测试覆盖:特别关注并发请求场景下的测试用例
总结
Soybean Admin 项目中遇到的并发请求刷新令牌问题,本质上是前端应用状态管理和异步流程控制的典型挑战。通过引入请求队列、优化拦截器逻辑或利用全局状态管理,可以构建更健壮的令牌刷新机制。这不仅解决了当前的问题,也为项目未来的扩展和维护打下了良好的基础。
登录后查看全文
热门项目推荐
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0231
GLM-5.2智谱开源 GLM-5.2,这是针对长文本任务的最新旗舰模型。相较于前代产品 GLM-5.1,它在长文本任务处理能力上实现了显著飞跃,并且首次在稳定的 100 万 token 上下文中提供这一能力。Jinja00
JoyAI-VL-Interaction-Preview京东开源首个开源、视觉驱动的实时交互模型——它能实时监控视频流,并自主决定何时发言、保持沉默或委托任务。Jinja00
cann-learning-hubCANN 学习中心仓,支持在线互动运行、边学边练,提供教程、示例与优化方案,一站式助力昇腾开发者快速上手。Jupyter Notebook0150
kornia🐍 空间人工智能的几何计算机视觉库Python02
PaddleParallel Distributed Deep Learning: Machine Learning Framework from Industrial Practice (『飞桨』核心框架,深度学习&机器学习高性能单机、分布式训练和跨平台部署)C++02
热门内容推荐
最新内容推荐
项目优选
收起
暂无描述
Dockerfile
782
5.11 K
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
892
2.06 K
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
471
473
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
710
1.43 K
deepin linux kernel
C
32
16
Ascend Extension for PyTorch
Python
763
972
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。
Python
2.27 K
681
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.11 K
1.15 K
本仓库是 Flutter SDK 与 Flutter Engine 的 OpenHarmony 适配版本,由 CPF-Flutter 团队维护。开发者可使用熟悉的 Flutter 技术栈开发 OpenHarmony 应用,3.35.7 及以后的适配版本可基于本仓库源码构建支持 OpenHarmony 的 Flutter Engine。
Dart
1.04 K
272
Claude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed.
Get Started
Rust
2.18 K
231