Redux Toolkit多store实现方案咨询：对比RTK Query与Fetch/Axios差异

首先你提到的嵌套Provider写法不推荐使用，官方文档提示的冲突确实存在：ApiProvider默认会创建独立的Redux Store实例，和外层普通Provider的Store完全隔离，不仅状态无法互通，还会出现DevTools冲突、中间件重复加载等问题，额外加ChosenStoreContext做切换的逻辑也属于冗余设计，完全可以用更简单的方案实现。

最优实现方案：整合RTK Query到现有RTK Store #

RTK Query本身就被设计为可以作为普通RTK Store的一个切片存在，不需要独立运行，你只需要修改现有普通Store的配置即可，步骤如下：

1. 修改configureStore配置，把RTKQ的Api实例整合进去

import { configureStore } from '@reduxjs/toolkit'
// 你已经创建好的RTKQ Api实例
import { demoApi } from './services/demoApi'
// 你原有使用Fetch/Axios的普通业务slice
import businessSlice from './slices/businessSlice'

export const store = configureStore({
  reducer: {
    // 注册普通业务slice的reducer
    business: businessSlice,
    // 注册RTKQ的reducer，key必须和你创建Api时定义的reducerPath一致
    [demoApi.reducerPath]: demoApi.reducer,
  },
  // 追加RTKQ的中间件，用于实现缓存、自动重连、数据无效化等内置能力
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(demoApi.middleware),
})

2. 移除嵌套的ApiProvider，整个应用只需要保留一层普通Provider即可

<Provider store={store}>
  {/* 所有应用组件 */}
</Provider>

对比两种实现的可选方案 #

整合到同一个Store之后，两种实现能力完全共存，不需要额外的Context做切换，你可以根据需求选以下两种对比方案：

• 不同功能模块分别实现：比如A模块用RTKQ的useQuery/useMutation钩子开发，B模块用普通RTK的异步Thunk+Axios/Fetch开发，互不干扰
• 同一功能做双实现对比：在组件内维护一个开关状态（可存在组件state或公共slice中），根据开关值决定调用RTKQ的查询钩子，还是调用普通slice的拉数方法即可，非常灵活。

内容的提问来源于stack exchange，提问作者adammo