基于thunk自实现Redux store与RTK Query有什么区别

• 设计定位完全不同：RTK Query 是专门为服务端状态缓存设计的高层抽象，所有内置逻辑都围绕「请求-缓存-更新-失效」这套服务端状态生命周期设计；而 thunk + createSlice 是 Redux 提供的通用底层原语，没有绑定任何特定业务场景，异步逻辑怎么写、状态结构怎么设计完全由你决定。
• 内置能力的覆盖度不同：RTK Query 开箱自带请求去重、竞态条件处理、缓存过期自动重拉、loading/error 状态托管、乐观更新、参数化缓存、分页/无限滚动适配这些通用数据获取能力，不需要你手动写任何重复逻辑；如果自己用 thunk + createSlice 实现，以上所有能力都要逐行手写——比如同一个接口短时间内被多个组件调用，你要自己写判断逻辑避免发重复请求；请求发出后参数变化，你要自己手动中断旧请求避免返回的旧数据覆盖新结果；每个接口对应的 slice 都要重复写 data/loading/error 三个字段和对应的更新逻辑，样板代码量非常大。
• 状态管控自由度不同：RTK Query 存在 Redux 里的缓存状态是内部托管的规范化结构，你不需要关心数据怎么存、怎么清理、怎么关联，直接用自动生成的 hooks 取数即可；自己写 createSlice 时，状态的字段设计、存储结构、更新时机完全可控，你可以根据业务需求做任意定制。
• 开发效率差异：常规的 CRUD 接口用 RTK Query 只需要在 createApi 里配置好请求地址、参数校验规则，就能直接拿到可用的 useQuery/useMutation 钩子，几行代码就能完成完整的数据获取逻辑；换成 thunk + createSlice 的方案，你需要先写 createAsyncThunk 处理异步请求，再在 slice 里写 pending/fulfilled/rejected 三个状态的 reducer，再写 selector 从 store 取数，必要时还要封装自定义 hooks 统一调用逻辑，整套实现的代码量是 RTK Query 的 5~10 倍。

RTK Query 不是用来替代所有 Redux 逻辑的银弹，它的能力边界非常明确：只负责管理有明确请求来源、需要缓存策略的服务端状态。碰到以下场景时，手动写 thunk + createSlice 是更合理的选择：

• 管理纯客户端状态：比如弹窗显隐、表单临时草稿、UI 主题配置、多步骤流程的中间态这类完全不来自服务端、也不需要缓存策略的状态，用 RTK Query 属于过度设计，直接写 slice 管理是最简单高效的方案。
• 实现高度定制化的复杂异步流程：比如涉及多接口串行/并行调用、跨模块状态联动、失败回滚的事务型逻辑（比如提交订单后需要联动清空购物车、跳转支付页、触发全局提示的完整流程），或者对接 WebSocket 维护长连接、增量更新实时数据的场景，RTK Query 固定的抽象范式反而会限制逻辑实现，用 thunk 自由编排流程的灵活度要高得多。
• 需要自定义状态结构的场景：如果业务数据需要和其他本地状态做深度联动，或者需要实现非常复杂的衍生状态计算，RTK Query 内部托管的缓存结构很难做深度定制，自己实现 slice 可以完全按照业务需求设计状态结构，后续迭代调整也不受抽象层约束。
• 极端定制化的缓存需求：比如做离线优先的 PWA 应用，需要自定义本地持久化策略、多端数据冲突合并逻辑时，RTK Query 提供的配置项不一定能覆盖需求，手动实现状态层的可控性会更高。

实际项目中完全不需要二选一，Redux 官方的最佳实践就是两者搭配使用：常规服务端接口的 CRUD 取数全交给 RTK Query 处理，省掉大量重复样板代码；纯客户端状态、复杂定制异步逻辑用 thunk + createSlice 实现，两者的状态共存于同一个 Redux store 中，互相调用也没有任何阻碍。

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