前言

你是否经历过这样的崩溃时刻——正在手机上编辑关键邮件/填写表单时。突然弹出「登录已过期,请重新登录」,刚写好的内容瞬间清空?或是逛电商App想加购商品,点击结算却被弹回登录页?这种「中途断流」的体验,不仅让使用者怒火中烧。更是前端项目留存率下降的隐形杀手!

在前后端分离架构下,Token 鉴权是主流方案。但 Token 有效期设置本身就是个两难:有效期短则频繁打扰,有效期长则安全风险高。话说回来，如何让 Token 「悄悄续命」。让使用者从不知道「登录过期」这件事?

一、为什么单 Token 总会「坑」到使用者?

先看一个扎心场景:假设你用某笔记App写方案。设置 Token 有效期 1 小时——如果写了 50 分钟突然切出去接

这就是单 Token 方案的死穴:

• 有效期短=频繁打扰: 使用者操作中断率飙升,体验极差;
• 有效期长=安全隐患: Token 一旦泄露,攻击者能长期盗用账号;

而双 Token 机制。就是为这个困局而生:

1. accesstoken: 短期有效,每次接口请求必带——泄露后风险窗口极短;
2. refreshtoken: 长期有效。仅用于 accesstoken 过期时「换全新令牌」——只要 user7天内活跃过,就能悄悄续命;

从简单说来看，accesstoken 管「当前操作安全」。refreshtoken 管「长期会话延续」——彻底告别「编辑到一半被赶下线」的噩梦!

二、主要流程:让「无感刷新」落地到底怎么走?

别以为「自动刷新」只是调用一次接口这么简单——它要精准覆盖 user 的每一次操作场景,确保「看不见才是最好」:

1. 日常操作:默默携带 accesstoken: 使用者浏览页面/提交评论时。前端自动从 localStorage/cookie 中取出 accesstoken,塞进 request header;

2. 触发异常:收到 401 Unauthorized: 如果 accesstoken 过期/失效,后端会返回标准错误码;

3. 智能判断:到底是哪个 token 挂了?:

   • - 如果是普通接口报401:只是 accesstoken 失效了,尝试用 refreshtoken 换新令牌;
   • - 如果连 refreshtoken 请求也报401:说明 refreshtoken 也过期了,只能强制跳登录页;

4. 完美兜底:悄悄重试失败请求: 获取新 accesstoken 和 refreshtoken 后。前端不仅更新本地存储,还会自动重发刚才失败的那个请求——user全程没察觉!

三、致命细节:如何搞定「并发请求风暴」?

想象一个极端场景:user 在 Token 刚过期时疯狂点击按钮。这3个请求会同时触发401错误——如果每个请求都去调 refresh_token接口,会发生什么?

• - 后端压力暴增:重复N次相同刷新请求;
-
• - 前端混乱:多个重复弹窗/报错提示。"程序错误""请重试",直接劝退 user;这就是「并发请求冲突」——而解决它的关键是一套"排队机制":
• 状态锁:用一个变量标记"当前是否正在刷新 Token"——避免重复发起刷新请求;
• 任务队列:把所有等待中的请求暂存在队列里;
• 批量回放:等 Token 刷新成功后,一次性执行队列里所有任务——就像什么都没发生过一样;

四、 Axios拦截器实战 :手把手写"零感知"代码

说了这么多,到底怎么落地?下面是基于 Axios 的完整实现——主要原因全藏在"拦截器"里,一行额外代码都不用写:

 import axios。{ AxiosRequestConfig } from 'axios';怎么说呢，interface PendingTask { config : AxiosRequestConfig;其实，resolve : Function;怎么说呢，} // -------------------主要状态管理------------------- let refreshing = false;// ✅状态锁:防止重复刷新Token let queue : PendingTask =;
// ✅任务队列:存等待中的请求 const axiosInstance = axios . create;// ------------------- 请求拦截器 :自动注入Token ------------------- axiosInstance . interceptors . request . use => { const accessToken = localStorage . getItem;if { config . headers . Authorization = Bearer ${accessToken};// ✅每次请求都带最新AccessToken } return config;})，// -------------------响应拦截器:处理Token过期------------------- axiosInstance . interceptors . response . use => response。async => { const { response : { data,config } = {} } = error || {};// -------------------情况1:已经在刷新中?先排队------------------- if { return new Promise => { queue . push;// ✅把当前请求丢进队列 });怎么说呢，} // -------------------情况2:Access Token过期?尝试刷新------------------- if ( data?. statusCode ===

jsx
=== undefined?"" : v，}

&&!config.url.includes) { refreshing = true;try { const refreshRes = await refreshToken;// ✅调用后端刷新接口 if throw new Error;// 更新双Token localStorage.setItem;localStorage.setItem;// -------------------关键:回放所有等待中的请求------------------- queue.forEach => resolve));queue =，// ✅清空队列 // ✅重发当前失败的那个 请求 return axiosInstance;} catch { refreshing = false;queue =，localStorage.clear;// ✅清除无效token window.location.href='/login';// ✅强制跳登录 return Promise.reject;} } // -------------------情况3:其他错误直接抛出------------------- return Promise.reject;})，/** * @desc
jsx
=== undefined?"" : v，}

获取新AccessToken和RefreshToken */ async function refreshToken { const res = await axios.get }});return res，}

五、避坑教程 :这些细节漏掉就前功尽弃!怎么说呢，

1. 别让 Promise "挂起"变"废弃":.refreshing=true 时返回未resolve 的Promise很关键!它会让 Axios 请求保持pending状态。"等我好消息",而不是直接报错;
2. >Refresh接口也要做"降级保护">:/api/auth/refresh >本身也可能返回4xx!必须捕获这种错误并直接清缓存跳登录——别让 user等半天还没反应;
red,.1)">强 security要求要用 HttpOnly Cookie!:localStorage >存refreshToken有XSS风险!如果项目涉及敏感信息,一定要把refreshToken存在HttpOnly Cookie里——浏览器脚本无法读取它;
别让 Refresh接口进入死循环!:/api/auth/refresh一定要排除在"需accessToken验证"之外!否则 accessToken过期后调 refresh接口也会返回401。"自己卡自己",死循环警告!