Redux Toolkit中RTK Query的Token管理问题解析

问题背景

在使用Redux Toolkit的RTK Query进行API请求时，开发者经常需要处理身份验证令牌的管理。一个典型场景是：通过TokenManager类来设置和获取访问令牌，然后在API请求的headers中自动添加Authorization头。

核心问题现象

开发者发现使用RTK Query的fetchBaseQuery时遇到了一个奇怪的现象：

1. 首次加载应用时，prepareHeaders中无法获取TokenManager中的令牌（返回null），导致API请求失败
2. 热重载后（如修改代码触发重新编译），令牌能够正常获取，API请求成功
3. 如果改用自定义的axiosBaseQuery实现，则一切正常

技术分析

TokenManager实现

TokenManager是一个简单的单例类，提供了设置和获取令牌的基本功能：

class TokenManager {
  private token?: string;

  setToken(token?: string) {
    this.token = token;
  }

  getToken(): string | undefined {
    return this.token;
  }
}

两种BaseQuery实现对比

1. fetchBaseQuery实现：

prepareHeaders: async (headers: Headers) => {
  const token = tokenManager.getToken();
  if (token) {
    headers.set('Authorization', `Bearer ${token}`);
  }
  return headers;
}

2. axiosBaseQuery实现：

axios.interceptors.request.use(req => {
  const request = req;
  const token = tokenManager.getToken();
  if (token) {
    request.headers.Authorization = `Bearer ${token}`;
  }
  return request;
});

问题根源

1. 热重载与单例问题：在React Native开发环境中，热重载可能导致单例实例被重新创建，造成状态不一致。axios的拦截器可能在热重载后重新注册，而fetchBaseQuery的prepareHeaders可能保留了旧的引用。

2. 时序问题：TokenManager的令牌设置可能发生在API查询初始化之后，导致首次获取令牌失败。axios的拦截器是动态的，可能在请求发出时才获取最新令牌。

3. React Native调试器影响：调试器的存在可能改变了代码执行时序，这也是为什么关闭调试器后问题重现的原因。

解决方案

1. 确保令牌提前设置：在应用初始化阶段就设置好令牌，避免时序问题。

2. 使用Redux状态管理：将令牌存储在Redux store中，通过getState()在prepareHeaders中获取，这是RTK Query推荐的做法。

3. 避免热重载问题：在开发环境中注意单例的使用，可以考虑使用模块缓存或全局变量来确保单例唯一性。

4. 调试器兼容处理：针对React Native调试环境做特殊处理，确保代码在有无调试器时行为一致。

最佳实践建议

对于RTK Query的认证方案，推荐以下实现方式：

// 使用Redux store中的token
prepareHeaders: (headers, { getState }) => {
  const token = (getState() as RootState).auth.token;
  if (token) {
    headers.set('authorization', `Bearer ${token}`);
  }
  return headers;
}

这种方式更加可靠，因为它：

• 直接与Redux状态集成
• 避免了单例管理的问题
• 提供了更好的可测试性
• 与RTK Query的设计理念更契合

总结

在React Native环境下使用RTK Query时，令牌管理需要特别注意时序和状态一致性问题。相比自定义的单例管理，利用Redux自身的状态管理机制是更可靠的选择。开发者应当理解不同BaseQuery实现的差异，并根据项目需求选择最适合的方案。