每个开发者都应该知道的 Refresh Token 实现中的隐藏部分
来源：dev.to — 2026-07-24
📋 概述
文章讲述了一个真实场景：React 仪表盘有 5 个并发的 API 请求在 JWT 过期那毫秒同时触发 401，导致 Axios 拦截器中的 naive 刷新逻辑产生竞态条件——第一个请求刷新后新 token 被后续请求的同步刷新覆盖导致全部失效。作者展示了如何使用 Promise 队列锁机制解决此问题。
🔑 核心要点
- 核心场景：5 个并发 API 调用在同一毫秒因 JWT 过期收到 401
- Naive 拦截器模式使用 isRefreshing 布尔标志来防止重复刷新——但这不够
- 竞态条件：第一个请求刷新获得 Token A，第二个请求同步刷新获得 Token B，Token A 被服务端失效
- 修复方案：Promise 队列锁机制——第一个 401 请求执行刷新，后续请求等待同一个 Promise 解析后使用同一 Token
- 需要处理的边界情况：刷新 token 本身也过期时强制登出、并发刷新请求的排队管理
- 另一个细节陷阱：错误详情检查中微小的逻辑差异可能导致整个锁机制失效
💡 金句
你泡了杯咖啡，午饭后打开应用刷新页面，然后 BAM！直接被冷血地踢回登录页面，连个友好的 Toast 都没有。
👍 0
👎 0
← 返回 Dev.to 首页