在当今的前端开发领域，单页应用早Yi占据统治地位。随之而来的，是基于 Token 的身份认证机制成为主流。然而这也带来了一个让无数开发者头疼的问题：Token 的时效性。想象一下用户正在填写一份长达几页的表单，或者正在浏览复杂的报表数据，就在他点击提交的一刹那，屏幕上弹出了“登录Yi过期，请重新登录”的提示。这种体验，简直糟糕透顶。

为了解决这一痛点，“无感刷新”技术应运而生。它的核心目标非常简单却极具挑战性：在用户毫无察觉的情况下自动geng新过期的身份凭证，确保业务流程的连续性。今天我们就来深入探讨一下如何在目前Zui火的两大框架——Vue3 和 React 中，优雅地实现这一功Neng。

一、 核心策略：双 Token 机制与拦截器艺术

在动手写代码之前，我们需要先理清思路。要实现“无感”，单纯靠前端死守是不够的，必须依赖一套成熟的“双 Token”机制。简单来说后端会颁发两把“钥匙”：一把是 AccessToken，它的有效期hen短，专门用来开门；另一把是 RefreshToken，有效期较长，专门用来在旧钥匙失效时去配一把新钥匙。

整个流程就像是一场精密的接力赛： 1. 前端发起请求，携带 AccessToken。 2. 后端校验，Ru果发现 Token 快过期了或者Yi经过期，返回特定的状态码。 3. 前端的“守门员”——HTTP 拦截器——捕捉到这个信号。 4. 拦截器立即拿出 RefreshToken，向后端的“换证接口”发起请求。 5. 拿到新的 AccessToken 后拦截器geng新本地存储，并重新发起刚才那个失败的请求。 6. 用户对此一无所知，只kan到页面数据正常加载。

当然这里还有一个极其关键的细节：如何防止并发请求导致的重复刷新？ 试想一下Ru果页面上同时发出了 5 个请求，且dou因为 Token 过期失败了难道我们要刷新 5 次 Token 吗？绝对不行。这不仅浪费资源，还可Neng导致逻辑混乱。所以我们需要一个“锁”机制，确保同一时刻只有一个刷新请求在飞。

二、 Vue3 实战：Composition API + Pinia 的完美组合

在 Vue3 的生态中，Pinia Yi经取代 Vuex 成为官方推荐的状态管理库。它的类型推断友好且简洁，非常适合用来管理 Token 这种全局状态。我们将把 Token 的存储、geng新以及刷新逻辑封装在 Pinia 的 Store 中。

1. 构建 Pinia 认证仓库

我们需要一个地方来存放这两个 Token，并提供刷新的核心方法。这里为了演示方便，我们暂时使用 localStorage，但强烈建议将 RefreshToken 存放在 HttpOnly Cookie 中以防止 XSS 攻击。

// stores/authStore.js
import { defineStore } from 'pinia';
import axios from 'axios';
export const useAuthStore = defineStore('auth', {
  state:  => ({
    accessToken: localStorage.getItem || '',
    refreshToken: localStorage.getItem || ''
  }),
  actions: {
    // geng新凭证并同步到本地存储
    updateTokens {
      this.accessToken = newAccess;
      this.refreshToken = newRefresh;
      localStorage.setItem;
      localStorage.setItem;
    },
    // 核心动作：刷新 Access Token
    async refreshAccessToken {
      try {
        // 调用后端的刷新接口
        const res = await axios.post('/api/auth/refresh', {
          refreshToken: this.refreshToken
        });
        const { accessToken, refreshToken } = res.data;
        this.updateTokens;
        return accessToken; // 返回新 Token 供拦截器使用
      } catch  {
        // Ru果连 RefreshToken dou失效了那就没救了清理状态并踢人去登录页
        this.clearTokens;
        window.location.href = '/login';
        return Promise.reject;
      }
    },
    clearTokens {
      this.accessToken = '';
      this.refreshToken = '';
      localStorage.removeItem;
      localStorage.removeItem;
    }
  }
});

2. 封装 Axios 拦截器：智Neng重试的奥秘

有了 Store，接下来就是编写 Axios 的响应拦截器。这里是“无感刷新”的灵魂所在。我们需要处理 401 错误，并利用一个全局变量 `refreshPromise` 来解决并发刷新的问题。

// utils/request.js
import axios from 'axios';
import { useAuthStore } from '@/stores/authStore';
// 创建 Axios 实例
const service = axios.create({
  baseURL: import.meta.env.VITE_API_BASE_URL,
  timeout: 10000
});
// 请求拦截器：自动携带 Token
service.interceptors.request.use(
   => {
    const authStore = useAuthStore;
    if  {
      config.headers.Authorization = `Bearer ${authStore.accessToken}`;
    }
    return config;
  },
   => Promise.reject
);
// 用于存储正在进行的刷新请求，避免重复
let isRefreshing = false;
let refreshSubscribers = ;
// 处理响应错误
const handleResponseError = async  => {
  const authStore = useAuthStore;
  const originalRequest = error.config;
  // Ru果不是 401 错误，或者Yi经重试过一次了直接放过
  if  {
    return Promise.reject;
  }
  // 标记为重试状态，防止死循环
  originalRequest._retry = true;
  // Ru果当前没有正在刷新的请求
  if  {
    isRefreshing = true;
    try {
      // 发起刷新
      const newToken = await authStore.refreshAccessToken;
      // 刷新成功，执行所有订阅者的回调
      refreshSubscribers.forEach);
      refreshSubscribers = ;
      // 修改当前请求的 Header 并重试
      originalRequest.headers.Authorization = `Bearer ${newToken}`;
      return service;
    } catch  {
      // 刷新失败，清除队列并报错
      refreshSubscribers = ;
      return Promise.reject;
    } finally {
      isRefreshing = false;
    }
  } else {
    // Ru果正在刷新，将当前请求加入订阅队列
    return new Promise => {
      refreshSubscribers.push => {
        originalRequest.headers.Authorization = `Bearer ${token}`;
        resolve);
      });
    });
  }
};
// 响应拦截器
service.interceptors.response.use(
   => response.data,
  handleResponseError
);
export default service;

3. 在组件中轻松调用

完成了上述封装，你在业务组件中就Ke以完全无视 Token 过期的存在了。就像平时一样发起请求，剩下的脏活累活dou由拦截器搞定。

// components/UserProfile.vue

三、 React 实战：Hooks + Context 的灵活运用

React 的生态中，Context API 是管理全局状态的标准方案。虽然逻辑与 Vue3 高度相似，但在实现细节上，我们需要特别注意 Hooks 的使用规则——拦截器不Neng直接使用 Hook，因此我们需要稍微变通一下。

1. 创建 AuthContext

我们需要一个 Context 来提供 Token 的状态和刷新方法，并通过 Provider 将其注入到应用顶层。

// context/AuthContext.js
import { createContext, useContext, useState } from 'react';
import axios from 'axios';
const AuthContext = createContext;
export const AuthProvider =  => {
  const  = useState || '');
  const  = useState || '');
  const updateTokens =  => {
    setAccessToken;
    setRefreshToken;
    localStorage.setItem;
    localStorage.setItem;
  };
  const refreshAccessToken = async  => {
    try {
      const res = await axios.post;
      const { accessToken: newAccess, refreshToken: newRefresh } = res.data;
      updateTokens;
      return newAccess;
    } catch  {
      updateTokens;
      window.location.href = '/login';
      return Promise.reject;
    }
  };
  return (
    
      {children}
    
  );
};
export const useAuth =  => useContext;

2. 初始化 Axios 拦截器

在 React 中，我们不Neng在 `axios.js` 文件中直接 `useAuth`。相反，我们需要一个初始化函数，在应用启动时调用，将刷新方法“注入”到拦截器中。

// utils/request.js
import axios from 'axios';
const service = axios.create({
  baseURL: process.env.REACT_APP_API_BASE_URL,
  timeout: 10000
});
let refreshHandler = null; // 保存刷新函数的引用
let isRefreshing = false;
let refreshSubscribers = ;
// 初始化拦截器，传入刷新方法
export const initInterceptors =  => {
  refreshHandler = refreshFn;
  service.interceptors.request.use(config => {
    // 这里简单从 localStorage 读取，也Ke以通过 Context 传递
    const token = localStorage.getItem;
    if  config.headers.Authorization = `Bearer ${token}`;
    return config;
  });
  service.interceptors.response.use(
    response => response.data,
    async error => {
      const originalRequest = error.config;
      if  {
        return Promise.reject;
      }
      originalRequest._retry = true;
      if  {
        isRefreshing = true;
        try {
          const newToken = await refreshHandler;
          refreshSubscribers.forEach);
          refreshSubscribers = ;
          originalRequest.headers.Authorization = `Bearer ${newToken}`;
          return service;
        } catch  {
          refreshSubscribers = ;
          return Promise.reject;
        } finally {
          isRefreshing = false;
        }
      } else {
        return new Promise(resolve => {
          refreshSubscribers.push(token => {
            originalRequest.headers.Authorization = `Bearer ${token}`;
            resolve);
          });
        });
      }
    }
  );
};
export default service;

3. 在应用入口处连接

Zui后一步，在 `App.js` 中，我们利用 `useEffect` 来完成这个“注入”过程。

// App.js
import React, { useEffect } from 'react';
import { AuthProvider, useAuth } from './context/AuthContext';
import { initInterceptors } from './utils/request';
import request from './utils/request';
const AppContent =  => {
  const { refreshAccessToken } = useAuth;
  useEffect => {
    // 初始化拦截器，并传入 Context 中的刷新方法
    initInterceptors;
  }, );
  // 测试请求
  const fetchData = async  => {
    try {
      const data = await request.get;
      console.log;
    } catch  {
      console.error;
    }
  };
  return (
    

      获取数据
    
  );
};
const App =  => {
  return (
    
      
    
  );
};
export default App;

四、 安全与性Neng的深度思考

虽然我们实现了功Neng，但作为负责任的开发者，还需要关注一些潜在的坑。

1. 安全存储：拒绝 XSS

这无异于给黑客留了一扇后门。XSS 攻击Ke以轻易窃取 localStorage 中的数据。因此，RefreshToken 务必存放在 HttpOnly Cookie 中。这种 Cookie 无法被 JavaScript 读取，浏览器会在请求时自动携带，安全性大大提升。Access Token Ke以存放在内存中，这样页面一关，它就消失了geng加安全。

2. 并发请求的队列管理

我们在 Vue 和 React 的实现中dou使用了“订阅者模式”来处理并发请求。这是解决“多个请求同时 401”的Zui佳实践。Ru果不加锁，可Neng会导致后端压力剧增，甚至因为 RefreshToken 并发使用而被后端判定失效。

3. 主动刷新 vs 被动刷新

目前的方案属于“被动刷新”，即等到 401 了才去刷新。这会导致用户的第一次请求会有轻微的延迟。Ru果对延迟极其敏感，Ke以引入“主动刷新”策略：利用一个定时器，在 Token 过期前几分钟自动发起刷新。这样用户在 Token 真正过期时手里永远拿着一张新鲜的票。

无论是 Vue3 的 Pinia 还是 React 的 Context，它们在实现 Token 无感刷新时的底层逻辑是殊途同归的。核心dou在于如何巧妙地利用 Axios 拦截器来捕获错误，以及如何利用锁机制来控制并发。希望这篇文章Neng让你在处理认证逻辑时geng加游刃有余，不再被突如其来的“登录过期”打断思路。毕竟Zui好的用户体验，就是让用户感觉不到技术的存在。

---