Axios 请求拦截器中更新授权头的技术解析

问题背景

在使用 Axios 进行 HTTP 请求时，开发者经常会遇到需要动态更新请求头的情况，特别是在处理 OAuth 2.0 或 JWT 认证时。当访问令牌过期后，需要刷新令牌并重新发送请求，这时就需要在拦截器中更新 Authorization 头。

核心问题分析

在 Axios 的拦截器机制中，当响应返回 401 未授权状态码时，开发者通常会尝试：

1. 刷新访问令牌
2. 更新请求配置中的 Authorization 头
3. 重新发送原始请求

然而，许多开发者发现即使更新了配置中的 headers 对象，重试的请求仍然使用了旧的授权头信息。

解决方案

通过深入分析 Axios 的内部机制，我们发现关键在于如何正确修改请求配置。以下是有效的解决方案：

1. 创建新的 headers 对象

直接修改 headers 属性可能不会触发 Axios 的内部更新机制。正确做法是创建一个新的 headers 对象：

config.headers = { ...config.headers };
config.headers.Authorization = `Bearer ${newToken}`;

2. 标记请求已重试

为了避免无限重试循环，需要标记请求：

config._retried = true;

3. 完整的拦截器实现

axiosPrivate.interceptors.response.use(
  response => response,
  async error => {
    const config = error.config;
    
    if (error.response?.status === 401 && !config._retried) {
      try {
        config._retried = true;
        const newToken = await refreshToken();
        
        // 关键步骤：创建新的 headers 对象
        config.headers = { 
          ...config.headers,
          Authorization: `Bearer ${newToken}`
        };
        
        return axiosPrivate.request(config);
      } catch (refreshError) {
        return Promise.reject(refreshError);
      }
    }
    return Promise.reject(error);
  }
);

技术原理

Axios 在内部处理请求配置时，会对 headers 进行特殊处理。直接修改现有 headers 对象的属性可能不会触发 Axios 的更新机制，因为：

1. Axios 可能对初始配置进行了深拷贝或冻结处理
2. 内部中间件可能只在新 headers 对象被赋值时才会更新请求头
3. 某些版本的 Axios 对配置对象的变更检测机制较为严格

最佳实践

1. 始终创建新的 headers 对象：这是最可靠的更新方式
2. 添加重试标记：防止因令牌刷新失败导致的无限循环
3. 错误处理：妥善处理令牌刷新失败的情况
4. 版本兼容性：不同版本的 Axios 可能有细微差异，需要测试验证

总结

在 Axios 拦截器中动态更新请求头需要特别注意对象的引用和更新方式。通过创建新的 headers 对象而非直接修改现有属性，可以确保授权头信息被正确更新并应用于重试的请求。这一技术点对于实现健壮的认证流程至关重要，特别是在处理 JWT 或 OAuth 2.0 令牌刷新场景时。