javascript技巧

关注公众号 jb51net

关闭
首页 > 网络编程 > JavaScript > javascript技巧 > 前端无感刷新token

前端实现无感刷新Token的方法与避坑指南

作者：前端Hardy

实现token无感刷新对于前端来说是一项非常常用的技术,今天,我们就来彻底搞懂如何真正实现无感刷新Token以及为什么 90% 的实现都有致命缺陷

刷新 Token 不是“过期就重新登录”，而是让用户毫无感知地继续使用。

可惜，大多数项目还在用 401 跳登录 粗暴处理——这根本不是用户体验，这是放弃治疗。

在现代 Web 应用中，用户登录后通常会获得一对 Token：

当 Access Token 过期时，理想状态是：前端自动用 Refresh Token 换取新 Token，并重试原请求——整个过程用户无感，页面不跳转、操作不中断。

但现实呢？

“Token 过期 → 弹出登录框 → 用户骂一句‘怎么又登出了’ → 关掉页面走人。”

今天，我们就来彻底搞懂：如何真正实现“无感刷新”Token？为什么 90% 的实现都有致命缺陷？

错误做法一：在每个接口里手动判断 401

// 千万别这么写！
fetch('/api/user')
  .then(res => {
    if (res.status === 401) {
      // 重新登录 or 刷新 token？
      window.location.href = '/login';
    }
  });

问题在哪？

错误做法二：全局拦截 401 后直接刷新 Token 并重试一次

这是目前最“主流”的错误方案：

// 伪代码：看似聪明，实则危险
axios.interceptors.response.use(
  res => res,
  async (error) => {
    if (error.response.status === 401) {
      const newToken = await refreshToken(); // 获取新 token
      saveToken(newToken);
      
      // 用新 token 重试原请求
      return axios(error.config);
    }
  }
);

表面看没问题，但隐藏三大坑

坑 1：并发请求雪崩

当页面刚加载，10 个接口同时发起，而此时 Token 已过期 ——10 个请求全部返回 401 → 触发 10 次 refreshToken() → 后端收到 10 个刷新请求！

后果：

坑 2：Refresh Token 泄露风险

如果前端把 Refresh Token 存在 localStorage，一旦 XSS 攻击成功，攻击者可长期盗用账号。

安全最佳实践：Refresh Token 应仅存于 HttpOnly Cookie，前端不可读！

但上述方案要求前端“拿到新 token”，这就逼你把 Refresh Token 暴露给 JS —— 安全与功能不可兼得？

坑 3：无限重试死循环

如果 refreshToken() 本身也返回 401（比如 Refresh Token 也过期了），重试原请求 → 又 401 → 再刷新 → 再 401 → ……

浏览器卡死，内存飙升。

正确方式：用“锁机制 + 队列 + 安全存储”三位一体

要实现真正的无感刷新，必须同时解决：

第一步：后端配合 —— Refresh Token 存 HttpOnly Cookie

HTTP/1.1 200 OK
Set-Cookie: refreshToken=abc123; HttpOnly; Secure; SameSite=Strict; Path=/auth

前端永远拿不到 refreshToken，但每次请求会自动携带。

第二步：前端实现“单例刷新锁 + 请求队列”

let isRefreshing = false;
let refreshPromise = null;
const failedQueue = [];

// 重试队列中的请求
const processQueue = (error, token = null) => {
  failedQueue.forEach(({ resolve, reject }) => {
    if (error) {
      reject(error);
    } else {
      resolve(token);
    }
  });
  failedQueue.length = 0;
};

axios.interceptors.response.use(
  response => response,
  async (error) => {
    const originalRequest = error.config;

    if (error.response?.status === 401 && !originalRequest._retry) {
      if (isRefreshing) {
        // 已在刷新中，将请求加入队列，等待新 token
        return new Promise((resolve, reject) => {
          failedQueue.push({ resolve, reject });
        }).then(token => {
          originalRequest.headers['Authorization'] = `Bearer ${token}`;
          return axios(originalRequest);
        });
      }

      originalRequest._retry = true;
      isRefreshing = true;

      try {
        // 调用刷新接口（后端从 Cookie 读 refreshToken）
        const { data } = await axios.post('/auth/refresh');
        const newAccessToken = data.accessToken;

        // 通知所有排队的请求
        processQueue(null, newAccessToken);

        // 重试当前请求
        originalRequest.headers['Authorization'] = `Bearer ${newAccessToken}`;
        return axios(originalRequest);
      } catch (refreshError) {
        // 刷新失败：清空本地身份，跳转登录
        clearAuth();
        processQueue(refreshError, null);
        window.location.href = '/login';
        return Promise.reject(refreshError);
      } finally {
        isRefreshing = false;
        refreshPromise = null;
      }
    }

    return Promise.reject(error);
  }
);

关键设计解析

机制作用
isRefreshing 锁确保同一时间只发起一次刷新
failedQueue 队列缓存所有因 401 失败的请求，等新 token 到手后批量重试
_retry 标记防止重试后的请求再次进入刷新逻辑
HttpOnly Cookie保护 Refresh Token 不被 XSS 窃取

安全补充：前端 Token 存储建议

Token 类型推荐存储方式原因
Access Token内存（JS 变量）或 sessionStorage短期有效，避免持久化泄露
Refresh TokenHttpOnly Cookie前端不可读，防 XSS

切勿将任何 Token 存入 localStorage！这是 XSS 攻击的黄金目标。

如何测试你的刷新逻辑

结语

“无感刷新 Token”不是炫技，而是对用户体验和系统安全的基本尊重。那些让用户频繁重新登录的产品，不是技术做不到，而是没把用户当回事。

真正的专业，藏在细节里：一个锁、一个队列、一个 HttpOnly Cookie —— 就是 10% 正确方案 与 90% 错误实现的分水岭。

你的项目还在用“401 就跳登录”吗？是时候升级了。

欢迎转发给那个总说“Token 过期就让用户重新登录”的同事。

到此这篇关于前端实现无感刷新Token的方法与避坑指南的文章就介绍到这了,更多相关前端无感刷新token内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文