本文详细阐述了如何利用 axios 拦截器实现 access token 的自动刷新机制。针对 access token 过期导致的 403 未授权错误，通过配置响应拦截器，在检测到特定错误码时，自动触发令牌刷新流程，更新授权头部并重试原请求，从而提升用户体验，避免频繁重新登录。
理解 Access Token 过期问题
在现代 Web 应用中，为了增强安全性，Access Token 通常会设置较短的有效期（例如一小时）。当 Access Token 过期后，客户端向受保护资源发起请求时，服务器会返回 401 Unauthorized 或 403 Forbidden 错误，导致用户需要重新登录才能继续操作，这严重影响了用户体验。为了解决这一问题，我们需要一种机制在 Access Token 过期时，能够静默地自动获取新的 Access Token。
Axios 拦截器：解决方案核心
Axios 作为流行的 HTTP 客户端库，提供了强大的拦截器（Interceptors）功能，允许我们在请求发送前或响应返回后进行处理。利用响应拦截器，我们可以捕获 HTTP 错误，并在 Access Token 过期时执行刷新操作。
实现自动刷新逻辑
实现 Access Token 自动刷新的核心在于配置 Axios 的响应拦截器。当一个 HTTP 请求返回错误时，拦截器会检查错误状态码。如果检测到 403 Unauthorized 错误，并且该请求之前没有被重试过，拦截器将尝试刷新 Access Token，然后用新的 Access Token 重新发起原始请求。
具体实现步骤如下：
- 捕获错误响应: 在 axiosApiInstance.interceptors.response.use 的第二个参数（错误处理函数）中捕获所有请求错误。
- 判断错误类型: 检查 error.response.status 是否为 403。
- 防止无限重试: 使用 originalRequest._retry 标志位确保每个失败的请求只重试一次，避免在刷新失败时陷入死循环。
- 执行令牌刷新: 调用一个异步函数（例如 refreshAccessToken()）来获取新的 Access Token。这个函数通常会使用 Refresh Token 向认证服务器请求新的 Access Token 和 Refresh Token。
- 更新授权头部: 成功获取新 Access Token 后，更新 Axios 实例的默认 Authorization 头部，确保后续请求使用新令牌。
- 重试原始请求: 使用新的 Access Token 重新发起之前失败的 originalRequest。
以下是实现这一逻辑的示例代码：
import axios from 'axios';
// 假设您有一个预配置的 Axios 实例
const axiosApiInstance = axios.create({
baseURL: '/api', // 您的 API 基础路径
timeout: 10000,
headers: {
'Content-Type': 'application/json',
// 初始的 Authorization header 可以在登录时设置
}
});
// 模拟刷新 Access Token 的函数
// 在实际应用中，此函数会使用 Refresh Token 调用认证服务接口
async function refreshAccessToken() {
console.log("尝试刷新 Access Token...");
// 假设这里调用了一个 API 来获取新的 Access Token
// 例如：const response = await axios.post('/auth/refresh-token', { refreshToken: storedRefreshToken });
// const newAccessToken = response.data.accessToken;
// 实际项目中，需要从本地存储获取 refreshToken，并更新本地存储的 accessToken
// 模拟异步操作
return new Promise(resolve => {
setTimeout(() => {
const newAccessToken = 'new_access_token_' + Date.now();
console.log("Access Token 刷新成功:", newAccessToken);
// 在这里您可能还需要更新本地存储的 refreshToken
resolve(newAccessToken);
}, 1500);
});
}
// 响应拦截器
axiosApiInstance.interceptors.response.use(
(response) => {
// 如果响应成功，直接返回
return response;
},
async function (error) {
const originalRequest = error.config;
// 检查是否为 403 错误且未重试过
// error.response 存在且状态码为 403，并且 originalRequest._retry 为 false (未重试过)
if (error.response && error.response.status === 403 && !originalRequest._retry) {
originalRequest._retry = true; // 标记为已重试
try {
// 尝试刷新 Access Token
const newAccessToken = await refreshAccessToken();
// 更新 Axios 实例的默认授权头部，影响所有后续请求
axiosApiInstance.defaults.headers.common['Authorization'] = 'Bearer ' + newAccessToken;
// 更新原始请求的授权头部，以便重新发送
originalRequest.headers['Authorization'] = 'Bearer ' + newAccessToken;
// 重新发送原始请求
return axiosApiInstance(originalRequest);
} catch (refreshError) {
console.error("Access Token 刷新失败:", refreshError);
// 如果刷新失败，或者 refreshAccessToken 函数内部决定重定向，
// 则可以导向登录页面，并清除本地存储的令牌信息
// window.location.href = '/login?error=session_expired';
return Promise.reject(refreshError); // 拒绝Promise，将错误传递下去
}
}
// 对于其他错误或已重试的 403 错误，直接拒绝Promise
return Promise.reject(error);
}
);
// 示例用法
async function fetchData() {
try {
// 假设在某些情况下，需要手动设置 Authorization header，或者它已经在登录时设置
// axiosApiInstance.defaults.headers.common['Authorization'] = 'Bearer ' + 'expired_access_token';
const response = await axiosApiInstance.get('/protected-data');
console.log("获取受保护数据成功:", response.data);
} catch (error) {
console.error("获取受保护数据失败:", error.response ? error.response.data : error.message);
}
}
// 模拟一个需要 Access Token 的请求
// fetchData();refreshAccessToken 函数的实现考量
refreshAccessToken 函数是整个自动刷新机制的关键。在实际应用中，它通常会执行以下操作：
- 获取 Refresh Token: 从本地存储（如 localStorage 或 sessionStorage）中获取存储的 Refresh Token。
- 发送刷新请求: 向认证服务器的刷新令牌接口发送 POST 请求，携带 Refresh Token。
-
处理响应:
- 如果成功，服务器会返回新的 Access Token 和（可能）新的 Refresh Token。将这些新令牌更新到本地存储。
- 如果失败（例如 Refresh Token 也过期或无效），则需要清除所有令牌，并将用户重定向到登录页面。
- 返回新 Access Token: 将新获取的 Access Token 返回给拦截器。
注意事项与最佳实践
- 防止无限重试: originalRequest._retry 标志至关重要，它能有效避免在 Access Token 刷新失败时导致请求无限循环。
- Refresh Token 的安全性: Refresh Token 具有更长的有效期，因此需要妥善存储。建议使用 HttpOnly cookie 或其他安全机制，避免 JavaScript 直接访问。
- 刷新失败处理: 如果 Refresh Token 也已过期或刷新请求本身失败，必须将用户重定向到登录页面，并清除所有本地存储的令牌信息，以确保安全性。
- 并发请求处理: 在 Access Token 刷新过程中，如果同时有多个请求因 403 错误而触发刷新，可能会导致多次不必要的刷新请求。一种优化方式是，当第一个刷新请求发出后，后续的 403 错误请求可以暂停，等待第一个刷新请求完成后，再使用新的 Access Token 重新发送。这可以通过一个队列或 Promise 链来实现。
- 用户体验: 自动刷新机制应尽可能对用户透明。只有在 Refresh Token 也失效时才提示用户重新登录。
- 认证端点排除: 刷新令牌的请求（例如 /auth/refresh-token）本身不应该被拦截器处理，因为它不需要 Access Token。在拦截器中添加条件，排除这些特定端点，防止它们被误拦截。
总结
通过巧妙地利用 Axios 拦截器，我们可以构建一个健壮的 Access Token 自动刷新机制。这不仅解决了 Access Token 短有效期带来的用户体验问题，减少了用户频繁登录的困扰，也提升了应用程序的整体可用性和专业性。正确实现这一机制，包括考虑 Refresh Token 的安全性、刷新失败的优雅处理以及并发请求的优化，是构建现代安全 Web 应用的关键一环。
