为什么要使用Redux Saga？其适用场景与核心价值问询

到底什么是副作用 #

别信那些绕来绕去的学术定义，判断标准非常简单：如果一段代码不是纯靠输入参数计算返回值，执行过程中会改外部状态、依赖外部可变值、或者和外部系统做交互，这部分逻辑就是副作用。
你示例里的setFetching改组件状态、myApiCall发网络请求、setData存接口返回、toast.error弹全局提示，全是副作用。纯函数不会有这些操作，输入固定输出就固定，不会对外界产生任何影响。

你举的按钮场景，用Saga纯属于脱裤子放屁 #

这个单按钮触发请求、带loading态、带错误提示的逻辑，是完全内聚在单个组件里的简单逻辑：

• 触发源只有这一个按钮的点击事件
• 没有复杂的并发、取消、分支流程需求
• 所有状态只给当前组件用，不需要跨组件共享
  这时候把async/await直接写在点击回调里就是最优解，代码短、逻辑直观、调试方便。硬套Saga的话，你得额外定义请求发起/成功/失败三个action、写saga监听函数、写Generator处理请求流程、在组件里dispatch action、从store里取loading和data状态，平白多了三四层抽象，代码量翻两三倍，你觉得它没价值太正常了——这个场景下它本来就没价值，属于典型的过度设计，就像你拿菜刀剪指甲，不好用不是菜刀的问题，是你用错了地方。

Saga从来不是用来替代组件内简单async/await的，它解决的是组件内零散写异步逻辑很难优雅搞定的复杂场景：

• 跨组件复用异步逻辑：比如拉取当前登录用户信息的逻辑，可能在登录成功后触发、可能在页面刷新鉴权时触发、可能在用户修改完个人资料后触发。你不需要在每个触发点都重复写「开loading→发请求→存数据→处理错误→关loading」的重复代码，只要统一dispatch一个fetchCurrentUser的action，所有流程都交给Saga统一监听处理就行。后续如果要加逻辑，比如先读本地缓存再决定要不要发请求，只需要改saga里的一处代码，所有触发点都不用动。
• 复杂异步流程控制：这是Saga最不可替代的能力，它提供的一系列effect方法，能让你用写同步代码的方式处理非常绕的异步逻辑，不用自己堆一堆标志位、取消令牌、全局定时器：
  • 防抖节流：比如搜索框输入停止300ms再发搜索请求，用户输入新内容时直接取消上一个还没返回的请求，避免旧结果晚返回覆盖新结果
  • 竞态处理：比如快速切换商品分类、快速点不同的详情页，你要保证最后展示的是用户最后一次操作对应的结果，而不是先返回的旧请求结果
  • 复杂流程编排：比如登录流程要先拉取图形验证码、再校验验证码换token、再用token拉用户信息、再并行拉用户的购物车和优惠券列表，其中任意一步失败都要做对应的回退处理
  • 全局常驻逻辑：比如全局WebSocket消息监听，收到不同类型的消息要触发不同的状态更新、弹提示、甚至触发其他接口请求，这种和具体组件无关的全局逻辑，不可能塞到某个组件的useEffect里
• UI和业务逻辑彻底解耦：组件层只需要做两件事：dispatch用户操作对应的action、根据store里的状态渲染UI，完全不需要关心这个操作背后是发请求、读缓存、还是做了一堆流程判断。后续业务逻辑调整的时候，组件代码一行都不用改。
• 异步逻辑可测试性强：Saga用Generator函数写的流程，每一步的effect都是普通JS对象，你不需要mock接口、不需要渲染组件，单步执行Generator就能验证每一步的逻辑是否正确，复杂流程的测试成本比散在各个组件里的async函数低很多。

说白了，Saga是给中大型应用的复杂全局异步逻辑准备的工具，小项目、简单逻辑硬上Saga就是自找麻烦。你现在觉得它没用，本质是还没遇到需要它解决的复杂度问题而已。

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