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

🧑‍💻 写在开头

点赞 + 收藏 === 学会🤣🤣🤣

刷新 Token 不是“过期就重新登录”，而是让用户毫无感知地继续使用。
可惜，大多数项目还在用 401 跳登录 粗暴处理——这根本不是用户体验，这是放弃治疗。

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

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

当 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，会触发多次刷新，甚至多次跳登录；
• 完全无法做到“无感”。

---

错误做法二：全局拦截 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 攻击成功，攻击者可长期盗用账号。

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

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

坑 3：无限重试死循环

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

---

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

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

1. 并发控制（只刷一次）
2. 安全存储（Refresh Token 不暴露给 JS）
3. 失败兜底（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);
  }
);

关键设计解析：

 

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

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

---

如何测试你的刷新逻辑？

1. 手动将 Access Token 设为过期；
2. 快速点击多个按钮，触发并发请求；
3. 观察 Network 面板：
   • 是否只调用了一次 /auth/refresh？
   • 所有原请求是否最终成功？
4. 模拟 Refresh Token 失效，是否跳转登录？

---

结语

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

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

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

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

如果对您有所帮助，欢迎您点个关注，我会定时更新技术文档，大家一起讨论学习，一起进步。