是否有必要使用Redux Saga + Axios替代RTK Query的createApi？

一、需要精细化控制复杂异步流 #

如果你的应用有特别复杂的异步操作流程——比如请求前要做好几步校验、请求过程中得根据实时状态随时中断或重试、请求完还要触发一堆跨模块的操作（比如同时更新好几个不相关的状态、发WebSocket消息、修改本地缓存的复杂逻辑），Redux Saga的生成器语法能把这些流程写得像同步代码一样线性，读起来更顺。对比之下，RTK Query虽然支持自定义queryFn和数据转换，但碰到分支多、步骤杂的长流程，Saga的take/put/call/race这些工具用起来更顺手，毕竟它本来就是为处理复杂异步场景设计的。

二、已有技术栈的历史惯性 #

要是项目已经用Redux Saga + Axios跑了很久，团队所有人都熟得不能再熟，而且没碰到性能或维护上的硬问题，那真没必要强行转RTK Query。迁移意味着要重构一大堆数据获取逻辑、重新定义API切片、调整状态结构，还要让团队重新学习新的用法——这种成本在项目稳定期完全没必要花。

三、想要完全掌控请求层细节 #

Axios本身是个灵活性拉满的HTTP客户端，你能全局配置拦截器、自定义请求/响应的转换规则、精细控制超时和错误处理。虽然RTK Query也支持用Axios当请求工具，但它的封装会在某些细节上限制你。比如你想给某个特定请求加独有的拦截逻辑，或者要直接用Axios的CancelToken来灵活取消请求，Saga+Axios的组合能让你直接调用Axios的原生API，不用绕RTK Query的规则。

四、不需要RTK Query的额外特性 #

RTK Query自带缓存、自动重取、轮询、乐观更新这些功能，但如果你的应用根本用不上——比如数据很少更新、不需要缓存，或者业务要求必须每次都拿最新数据，那这些特性反而成了冗余。这时候用Saga+Axios这种更轻量的组合，反而能减少不必要的状态管理复杂度。

关于RTK Query的成熟度 #

RTK Query现在已经非常成熟，是Redux官方推荐的数据获取方案，能覆盖绝大多数常规业务场景：比如CRUD、分页、搜索、缓存管理这些需求，用它实现比Saga+Axios简洁多了，不用自己写重复的加载/错误/成功状态管理，也不用手动处理缓存失效。如果是新项目，或者业务场景比较常规，RTK Query绝对是更高效的选择。

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