您的位置: 首页> Vue

前端如何实现“无感刷新”Token？90% 的人都做错了

匿名上传

发布时间:2026-03-25 21:48:01

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

Access Token（短期有效，如 15 分钟）
Refresh Token（长期有效，如 7 天）

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

但现实呢？

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

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

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

问题在哪？

每个接口都要重复写逻辑；
如果多个请求同时 401，会触发多次刷新，甚至多次跳登录；
完全无法做到“无感”。

错误做法二：全局拦截 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 个刷新请求！

后果：

后端可能拒绝重复刷新（安全策略）；
Refresh Token 被提前消耗，后续真失效；
用户反而被踢下线。

坑 2：Refresh Token 泄露风险

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

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

坑 3：无限重试死循环

如果 refreshToken() 本身也返回 401（比如 Refresh Token 也过期了），
→ 重试原请求 → 又 401 → 再刷新 → 再 401 → ……
浏览器卡死，内存飙升。

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

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

并发控制（只刷一次）
安全存储（Refresh Token 不暴露给 JS）
失败兜底（Refresh 失败时优雅降级）

第一步：后端配合 —— 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 窃取