小明盘下了一家叫「菜色大师」的餐厅，生意火爆，后厨却乱成一锅粥。服务员小美接到 7 号桌加菜，直接朝后厨喊一嗓子；大厨凭记忆做菜，账本上却记着别的数字；传菜员端着菜找不到桌号。每个人都想帮忙，但没一套规矩，信息就变成了噪音。 小明决定引入一套“餐厅管理系统”：客人要什么，就写进一张点菜单（Action）；大厨只认点菜单和现有库存，按规矩做出新菜（Reducer）；所有订单和食材记录在唯一一本总台账里（Store）；订单进厨房前，先过主管台，记录日志、检查合理性（中间件）；遇到要“等”的复杂菜式——炖汤、烤鸭——总厨助理掏出可暂停的料理清单，一步一等、条件满足再继续（Redux-Saga 的 Generator）。 这套系统把自由的即兴沟通变成了规范的单向流水线。它解决的不只是餐厅的问题，也是前端应用里组件间状态混乱的问题。本文就带你沿着这条流水线，从 Redux 的核心概念走到 Saga 的异步实战。

岗位关联

掌握 Redux 与 Redux-Saga，意味着你拥有了把复杂前端状态“规范化、可预测化”的工程能力，这是从“能写页面”迈向“能架构大型应用”的关键一步。

目录
  1. 可视化演示
  2. 状态管理痛点：后厨的“喊话式”沟通
  3. 三大核心概念：点菜单、大厨与总台账
  4. 单向数据流：一条不能回头的传菜流水线
  5. Store 与 Reducer：账本规则与后厨分工
  6. 中间件机制：厨房门口的主管台
  7. Redux-Saga 原理：总厨助理的料理清单
  8. Effect 与实战：后厨的 SOP 手册
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示Redux数据流与Saga中的核心机制，通过概览/流程/对比/趋势四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Redux数据流与Saga中：Redu Redux数据流与action 纯函数reducer与不可变数 核心机制可视化 Redux数据流与Saga中整体架构与关键组件

状态管理痛点：后厨的“喊话式”沟通

刚接手餐厅时，小明发现服务员传话全屏嗓子：小美朝后厨喊“7 号桌加份红烧肉”，二厨应了一声，但账房先生记的是另一回事。等客人催菜，服务员又得从前厅跑到后厨再问一遍。这种“点对点喊话”看似自由，实则每个环节都可能失真，人一多就彻底失控。

React 应用也一样。没有 Redux 时，组件之间传数据靠 props 层层下传、回调层层上报。爷爷组件要把一个值传给深埋在五层之下的孙组件，中间每一层都得“转手”；兄弟组件要共享数据，只能把状态提升到最近的共同父级。组件一多，通信连线就成了蛛网。

技术上讲，n 个组件两两通信的连线数是一个组合数问题：

小明想明白了一个道理：与其让每个人互相喊话，不如设一个总台账，所有人都只跟台账对话。于是，Redux 的三样核心工具登场了。

C(n)=(n2)=n(n−1)2\displaystyle C(n)=\binom{n}{2}=\frac{n(n-1)}{2}
当组件数为 n 时，潜在通信连线按平方级增长，这就是“状态管理痛点”的数学本质。
  1. 组合数符号C(n) 表示从 n 个组件中任选两个建立通信连线的所有组合数。
    C(n)=(n2)C(n)=\binom{n}{2}
  2. 乘积项每个组件都可能与其余 n-1 个组件传值，先得到 n(n-1)。
    n(n−1)n(n-1)
  3. 除以 2A 传 B 和 B 传 A 是同一条通信关系，要除以 2 去重。
    n(n−1)2\frac{n(n-1)}{2}
  4. 增长趋势n 变大时连线数接近 n² 的一半，沟通通路爆炸式增长，这正是集中式 Store 要解决的问题。
    C(n)≈n22C(n)\approx\frac{n^{2}}{2}

三大核心概念：点菜单、大厨与总台账

小明的新制度有三样东西：客人把需求写进点菜单；大厨只认点菜单和现有食材，算出“该上什么菜”；总台账唯一记录所有订单和库存。三样东西各司其职，谁也不用喊话。

对应到 Redux，这三样就是 Action、Reducer 和 Store。Action 是一个带 type 字段的普通 JavaScript 对象，例如 { type: 'ADD_TODO', payload: '学习Redux' }，它只描述“发生了什么”，不干任何活。Reducer 是一个纯函数，接收旧状态和 action，返回新状态——它不修改入参，也不碰网络、不读日期，保证同样的输入永远得到同样的输出。Store 则是整个应用唯一的“数据仓库”，通过 getState() 读取状态树。

三者之间的关系可以用一个简洁的公式概括：

点菜单、大厨、总台账三件套建立后，后厨第一次有了“所有信息只走一条路”的秩序。但小明很快发现，光有工具还不够，还得规定这条路的行走方向。

nextState=reducer(prevState, action)\displaystyle \text{nextState}=\text{reducer}(\text{prevState},\ \text{action})
reducer 就像一个“输入-输出”规则机：喂给它旧状态和动作，它吐出新状态，除此之外什么都不做。
  1. prevState 旧状态reducer 的第一个参数，代表更新前完整的应用状态。
    prevState\text{prevState}
  2. action 动作描述带 type 和可选 payload 的普通对象，说明“发生了什么”。
    action={ type, payload }\text{action}=\{\ \text{type},\ \text{payload}\ \}
  3. reducer 纯函数计算不修改任何入参，只负责算出新状态并返回。
    reducer(⋅, ⋅)\text{reducer}(\cdot,\ \cdot)
  4. nextState 新状态reducer 的返回值会成为 Store 里唯一的新状态。
    nextState\text{nextState}

单向数据流：一条不能回头的传菜流水线

小明给餐厅定了规矩：客人说话 → 服务员填单 → 订单送进厨房 → 大厨做菜 → 总台账记录 → 传菜员上菜。每一步都有明确顺序，从不倒着走。这样做最大的好处是：任何环节出问题，查记录就能定位，没人能扯皮。

Redux 的设计正是如此。用户界面里发生交互（比如点击按钮），组件调用 store.dispatch(action)；action 被 reducer 收取并计算新状态；Store 保存新状态并通过订阅机制通知所有订阅者，React-Redux 收到通知后触发组件重新渲染。整个过程画成图就是一个单向闭环：

因为方向唯一，每一次状态变化都能被完整追踪，甚至可以“时光倒流”回放到任意历史时刻。这让小明对账本越来越有信心，他开始细化账本的记录规则。

View→  dispatch  Action→  reducer  newState→  subscribe  View\displaystyle \text{View}\xrightarrow{\;\text{dispatch}\;}\text{Action}\xrightarrow{\;\text{reducer}\;}\text{newState}\xrightarrow{\;\text{subscribe}\;}\text{View}
视图发起、动作传递、计算产生新状态、状态再回流到视图，方向永远顺时针，绝不回头。
  1. dispatch 派发store.dispatch(action) 是触发状态更新的唯一入口，相当于服务员写点菜单。
    View→dispatchAction\text{View}\xrightarrow{\text{dispatch}}\text{Action}
  2. reducer 计算纯函数根据 action 内容算出新状态，相当于大厨根据菜单做菜。
    Action→reducernewState\text{Action}\xrightarrow{\text{reducer}}\text{newState}
  3. subscribe 通知Store 调用订阅回调，驱动 React 组件以新数据刷新界面。
    newState→subscribeView\text{newState}\xrightarrow{\text{subscribe}}\text{View}
  4. 环路闭环更新后的视图再次产生交互，开启新一轮数据流，形成可预测的循环。
    View更新→Action新一轮\text{View}_{更新}\to\text{Action}_{新一轮}

Store 与 Reducer：账本规则与后厨分工

小明给总台账定了三条规矩：第一，台账由 createStore 建立，全店只有这一本；第二，大厨要分工——凉菜厨师管凉菜线、热菜厨师管热菜线，各记各的账，最后由总厨汇总；第三，账本绝不涂改——每出一道新菜，就在新账页上誊写最新库存，旧账页保留归档。

Redux 的技术实现与之对应。createStore(reducer, preloadedState, enhancer) 创建唯一的 Store。当应用状态复杂时，用 combineReducers({ order: orderReducer, stock: stockReducer }) 把多个子 reducer 合并成一个根 reducer，每个子 reducer 只负责自己的状态切片。而“不涂改账本”就是不可变更新：用展开运算符生成新对象，如 { ...state, count: state.count + 1 }，数组用 [ ...arr, newItem ] 而不是 arr.push()。

Store 的创建流程可以归纳为一个公式：

有了明确分工和“誊写”规则，后厨再也不会出现账实不符。但小明还发现，有些事不该让大厨分心——比如记录每张菜单的来源、检查菜品是否合理。这些杂活需要一个独立的关卡。

store=createStore(rootReducer, preloadedState, enhancer)\displaystyle \text{store}=\text{createStore}(\text{rootReducer},\ \text{preloadedState},\ \text{enhancer})
创建 Store 就像开账本：准备好归约函数、可选初始数据、可选增强器，三样齐了账本才正式启用。
  1. rootReducer 根归约函数通常由 combineReducers 把多个子 reducer 汇总成一个。
    rootReducer=combineReducers({ a,b,c })\text{rootReducer}=\text{combineReducers}(\{\ a,b,c\ \})
  2. preloadedState 初始状态可选参数，用于服务端渲染注水或恢复持久化数据。
    preloadedState\text{preloadedState}
  3. enhancer 增强器applyMiddleware(...) 返回的组合函数，用来增强 dispatch 能力。
    enhancer=applyMiddleware(m1, m2, m3)\text{enhancer}=\text{applyMiddleware}(m_1,\ m_2,\ m_3)

中间件机制：厨房门口的主管台

小明在厨房门口设了一张主管台：每一张点菜单递进厨房前，都必须先过主管。主管可以登记日志、核对食材库存、如果发现菜已下架就直接改单，甚至能截下特殊订单自己调度。大厨呢？大厨完全不知道主管的存在，他只管接单做菜。

Redux 的中间件就是这张主管台。中间件是一个“站在 dispatch 和 reducer 之间的函数”，它能看到每个经过的 action，可以选择放行（调用 next(action)）、记录日志、做异步处理，也可以直接吞掉不再向下传递。applyMiddleware(m1, m2, m3) 会把多个中间件串成一条链，最终包裹住原始的 dispatch。Redux-Thunk 和 Redux-Saga 本质上都是这种中间件的具体实现。

中间件组合后的 dispatch 可以用函数复合表达：

主管台让日志、异步、权限检查都能在进厨房前统一完成，业务代码（大厨）保持干净。但小明遇到的新难题是：有些菜要“等”——炖汤要等半小时，烤鸭要等腌料入味。普通主管台没法站在炉子前干等，于是他想到了一个更聪明的角色。

dispatchenhanced=m1∘m2∘m3 (dispatchraw)\displaystyle \text{dispatch}_{enhanced}=m_{1}\circ m_{2}\circ m_{3}\ (\text{dispatch}_{raw})
增强后的 dispatch 是“俄罗斯套娃”：最外层中间件先看到 action，层层内嵌，最后才轮到原始 dispatch。
  1. 原始 dispatchStore 自带、未经过任何加工的派发函数。
    dispatchraw\text{dispatch}_{raw}
  2. 组合符号∘ 表示函数从右向左嵌套调用，m3 最靠近原始 dispatch。
    m1∘m2∘m3m_{1}\circ m_{2}\circ m_{3}
  3. 增强后的 dispatchaction 依次经过每个中间件加工，最终调用原始 dispatch 送达 reducer。
    dispatchenhanced=m1(m2(m3(dispatchraw)))\text{dispatch}_{enhanced}=m_{1}(m_{2}(m_{3}(\text{dispatch}_{raw})))

Redux-Saga 原理：总厨助理的料理清单

小明给餐厅配了一位总厨助理，专门处理“需要等待”的菜。助理手里有一本料理清单，上面写着：第一步，等顾客确认口味；第二步，通知备菜；第三步，等食材送达；第四步，下锅炖煮；第五步，上菜。每走到一个“等”字，助理就把清单夹在架子上，转头去忙别的；条件满足了，再回来接着往下执行。助理绝不在原地干耗。

Redux-Saga 的核心正是这种“可暂停的清单”——ES6 的 Generator 函数。function* saga() {...} 执行后返回一个迭代器，函数体不会立即执行；每次调用 next() 才推进到下一个 yield 暂停点。Saga 中间件把 action 按类型分发给对应的 worker saga，worker 用 effect 描述它想等什么、想发什么：take(type) 表示“等待一个某类型的 action”，put(action) 表示“派发一个 action 给 reducer”。最重要的是，effect 只是一个普通对象，Saga 引擎负责真正执行，这让异步流程可以像普通数据一样被测试。

一次“等待后恢复”的过程可以用公式表达：

料理清单让复杂的“等多步”菜式有了条理，后厨不再靠记忆催菜。助理渐渐把常用套路沉淀成了标准作业流程，这就是我们要讲的最后一个话题——Effect 与实战。

action=yield take(ACTION_TYPE)\displaystyle \text{action}=\text{yield}\ \text{take}(\text{ACTION\_TYPE})
这一行读作：“暂停在这里，等一个 ACTION_TYPE 类型的动作；它到来时，那个动作就是 yield 的值，清单接着往下翻。”
  1. yield 暂停点生成器在此交出控制权，把执行权还给 Saga 引擎。
    yield\text{yield}
  2. take 声明take 是一个 effect 描述对象，告诉引擎“我想等某个类型的 action”。
    take(ACTION_TYPE)\text{take}(\text{ACTION\_TYPE})
  3. action 作为返回值当匹配的 action 到达，它成为 yield 表达式的结果，生成器从暂停处恢复执行。
    action=yield take(⋯ )\text{action}=\text{yield}\ \text{take}(\cdots)

Effect 与实战：后厨的 SOP 手册

总厨助理把日常遇到的订单情况总结成一套标准作业手册：同一种菜单来一张处理一张，用 takeEvery；客人反复改单只认最后一版，用 takeLatest；几道菜可以同时开炖，用 all 并行等待；某一步失败要按预案补救，用 try/catch 包住整个流程。新来的帮厨照着手册做，服务质量就有保障。

Redux-Saga 的常用 effect 正是这套手册的条款。takeEvery(pattern, worker) 每次匹配到 action 都启动一个 worker；takeLatest 则在新 action 到来时取消上一次未完成的任务，非常适合处理搜索防抖和重复提交。call(fn, ...args) 以可测试的方式调用异步函数；fork 启动一个不阻塞父级的子任务；all 并发执行并等待全部结果；race 让多个 effect 竞争，先完成者胜出。实战中一个典型的“用户下单”流程是：监听 SUBMIT 动作 → put 一个“加载中”状态 → call 请求后端 API → put 成功或失败的 action → put 清除加载状态，全程包在 try/catch/finally 里保证不出血漏。

Saga 的能力清单可以抽象成一个集合：

这份 SOP 手册，就是 Redux-Saga 给前端异步世界带来的最大礼物：复杂流程被拆成一行行清晰的“等待与执行”，看得见、测得了、控得住。整套餐厅管理系统到此闭环，小明终于能安心当翘脚老板了。

effect∈{ take, put, call, fork, all, race }\displaystyle \text{effect}\in\{\ \text{take},\ \text{put},\ \text{call},\ \text{fork},\ \text{all},\ \text{race}\ \}
记住这个集合，就等于拿到了 Saga 的完整工具箱：监听、派发、调用、分叉、并行、竞争，六件套各管一摊。
  1. take 监听等待某个 action 出现，常用于流程入口，比如登录请求的发起。
    take(LOGIN_REQUEST)\text{take}(\text{LOGIN\_REQUEST})
  2. put 派发把新的 action 交还给 reducer，相当于助理把指令递给大厨。
    put(action)\text{put}(\text{action})
  3. call 调用调用异步函数并等待结果，是“可测试的异步”关键。
    call(api.fetchUser, id)\text{call}(\text{api.fetchUser},\ id)
  4. 并发类 effectfork/all/race 控制任务的分叉、并行和竞争，处理复杂编排。
    all([ effect1, effect2 ])\text{all}([\ \text{effect}_{1},\ \text{effect}_{2}\ ])

AI 应用场景

场景一：LLM 对话应用的状态管理

阶段：前端应用层 / 对话状态管理

解决的问题：传统做法把消息列表存在组件 local state 里，用户切换页面或重连后就丢失；多轮对话的并发请求也容易错乱。用 Redux 统一管理消息数组，配合 Redux-Saga 处理异步，状态变得集中且可回溯。

具体案例：一个 AI 聊天面板中，用户点击发送后组件立刻 dispatch(sendMessage(text))；Saga 用 takeLatest 监听发送动作（用户连续追问时自动取消上一轮未完成的请求），call 调用大模型 API，流式返回时逐段 put(appendToken(...)) 更新界面，出错则 put(setError(...))。整个过程用户感知流畅，后端出问题也有兜底 UI。

场景二：AI Agent 工具调用编排面板

阶段：Agent 编排层 / 工具调用工作流

解决的问题：Agent 执行一个任务往往要调用多个工具（搜索、代码解释、数据库查询），每步都可能超时或失败。用 Redux 存执行日志和中间结果，用 Saga 的 all 并行发起工具调用、race 与定时器竞争实现超时控制、cancel 随时中止多余任务。

具体案例：数据分析 Agent 面板上，用户发起“分析这份 CSV 并画图”。Saga 先 put 一个 RUNNING 状态，fork 并行启动数据清洗和特征统计两个子任务，race 与 30 秒定时器竞争；任一任务完成就 put 更新执行日志，前端实时渲染每个工具调用的状态与耗时。

Python 演示

python93 行
# -*- coding: utf-8 -*-"""mini_redux.py - 用 Python 模拟 Redux 单向数据流与 Saga 生成器异步流程"""import time  class Store:    """迷你 Redux Store: 保存状态, 派发动作, 通知订阅者"""     def __init__(self, reducer, initial_state):        self._state = dict(initial_state)        self.reducer = reducer        self._subscribers = []        self._middleware_chain = []     def get_state(self):        return self._state     def subscribe(self, callback):        self._subscribers.append(callback)     def use(self, middleware):        self._middleware_chain.append(middleware)     def dispatch(self, action):        for middleware in self._middleware_chain:            if middleware(self, action):                return        self._state = self.reducer(self._state, action)        for callback in self._subscribers:            callback(self._state)  def counter_reducer(state, action):    """纯函数: 输入旧状态和 action, 输出新状态, 不修改入参"""    if action["type"] == "INCREMENT":        return {"count": state.get("count", 0) + action["payload"]}    if action["type"] == "DECREMENT":        return {"count": state.get("count", 0) - action["payload"]}    return state  def log_middleware(store, action):    print("[log] 中间件拦截 action:", action["type"])    return False  def add_async_saga(action):    """Saga worker: 用生成器描述分步异步流程"""    print("[saga] 开始处理, 模拟请求后端...")    yield "waiting"    time.sleep(0.5)    print("[saga] 后端返回, 派发 INCREMENT")    yield {"type": "INCREMENT", "payload": action["payload"]}  def run_generator(gen, store):    result = None    while True:        try:            step = gen.send(result)            if step == "waiting":                result = None            elif isinstance(step, dict):                store.dispatch(step)                result = None        except StopIteration:            break  def saga_middleware(store, action):    if action["type"] != "ASYNC_INCREMENT":        return False    run_generator(add_async_saga(action), store)    return True  if __name__ == "__main__":    store = Store(counter_reducer, {"count": 0})    store.use(log_middleware)    store.use(saga_middleware)     def render(state):        print("[view] 界面刷新, count =", state["count"])     store.subscribe(render)     print("== 同步流程 ==")    store.dispatch({"type": "INCREMENT", "payload": 3})     print("== Saga 异步流程 ==")    store.dispatch({"type": "ASYNC_INCREMENT", "payload": 7})     print("最终状态:", store.get_state())
目的：该脚本用 Python 还原了 Redux 的 Store、纯函数 Reducer、中间件链，以及基于生成器的 Saga 异步工作流，跑一遍就能直观看到“同步 dispatch”和“Saga 异步后 put”两种数据流。
  1. self._state = self.reducer(self._state, action)Store 收到 action 后调用 reducer 纯函数，用返回值覆盖旧状态，这是单向数据流的“计算”环节。
  2. if middleware(self, action):中间件链先于 reducer 执行，返回 True 表示已拦截处理，action 不再进 reducer。
  3. def add_async_saga(action):这是生成器函数；直接调用不会执行函数体，只会创建生成器对象。
  4. step = gen.send(result)每次 send 把执行权推进到下一个 yield 暂停点，这是 Saga 暂停/恢复的核心机制。
  5. time.sleep(0.5)模拟网络请求需要等待的异步耗时，对应实际项目里的 API 调用。
  6. store.dispatch(step)等价于 Saga 的 put(effect)：把新 action 重新派发回 store，完成“异步完成后更新状态”。
  7. store.use(log_middleware)注册中间件，好比 applyMiddleware(logMiddleware, sagaMiddleware) 组合中间件链。

常见误区

误区我调用 `store.dispatch` 之后，以为要等网络返回或下一帧才能拿到新状态，经常写一个 `setTimeout` 再去读。

正解dispatch 本身是同步的——它同步地走完中间件链、调用 reducer、通知所有订阅者。dispatch 之后立刻 getState() 就能拿到新状态。真正异步的是 Saga 或 thunk 里“做完请求、再 put 一个新 action”，那个新 action 的 dispatch 依然是同步的。

为何常见：实战中常看到“Saga 派发的 action 稍后才出现”的体验，让人误以为 dispatch 本身是异步的。

误区觉得 JavaScript 对象是引用类型，直接 `push` 或改字段再把原对象返回，既省内存又方便。

正解Redux 要求 reducer 返回“新引用”。如果返回同一个对象，React-Redux 做浅比较时会认为状态没变，界面不刷新；时间旅行调试也会因为历史状态被改坏而失效。正确做法是用展开运算符拷贝，例如 { ...state, count: state.count + 1 }。

为何常见：JS 引用类型太“好用”，新手习惯就地修改，忽略了“引用相等等于没变化”的检测机制。

误区我写了一行 `yield take('LOGIN')`，担心页面从此假死，点击任何按钮都没反应。

正解生成器的“暂停”只是暂停自身任务，不是阻塞线程。take 等待期间浏览器照常渲染、响应事件，只是这个 saga 任务在等指定 action。可以把它想象成服务员把“等汤好”写进清单就去招呼别的客人，而不是站在炉子前干等。

为何常见：把同步语言里的“阻塞”和生成器协作式暂停混为一谈。

误区看完教程觉得 Saga 最强大，所有接口请求都应该交给 Saga 管理，组件里绝不能出现任何异步逻辑。

正解简单的一次性请求用 thunk 或在组件 effect 里处理更轻量；Saga 的价值在于复杂编排：多步骤流程、取消任务、竞态处理、并行任务。杀鸡用牛刀会让项目结构过度复杂，难以维护。

为何常见：教程集中讲 Saga 的强项，很少强调“什么时候不需要它”，新手容易把它当万能异步工具。

面试题

Q1. Redux 中 action 的本质是什么？

单选题 · easy

  • A.描述事件的普通对象← 正确答案
  • B.保存状态的容器类
  • C.执行计算的纯函数
  • D.拦截请求的处理器

答案：A。action 是一个带 type 字段的普通 JS 对象，只描述“发生了什么”，不负责计算也不负责存储。Reducer 才是计算者，Store 才是容器，中间件才负责拦截。

Q2. Redux 中 reducer 的职责是？

单选题 · easy

  • A.保存全局状态树
  • B.派发 action 动作
  • C.计算并返回新状态← 正确答案
  • D.监听状态变化刷新

答案：C。reducer 是纯函数 (state, action) => newState；Store 负责保存状态，dispatch 负责派发动作，subscribe 负责监听变化，三者的职责不能混淆。

Q3. Redux 单向数据流的正确顺序是？

单选题 · easy

  • A.View 直接修改 Store 状态
  • B.View 派发 Action 触发 Reducer← 正确答案
  • C.Reducer 先执行再生成 Action
  • D.Store 主动推送状态给 Reducer

答案：B。单向数据流是 View → dispatch(action) → reducer → store → subscribe 驱动 View 更新。View 不能直接改状态，Reducer 不会自己产出 Action，Store 也不会主动推给 Reducer。

Q4. 关于不可变更新，正确的做法是？

单选题 · mid

  • A.直接 push 新元素到原数组
  • B.修改嵌套对象里的某个字段
  • C.用展开运算符生成新对象← 正确答案
  • D.把旧 state 原样返回

答案：C。Redux 要求 reducer 返回新引用，展开运算符 { ...state } 或 [ ...arr ] 是标准做法。直接 push、改字段或原样返回都会导致浅比较认为状态没变，UI 不刷新。

Q5. combineReducers 的主要作用是？

单选题 · mid

  • A.合并多个组件为一个整体
  • B.合并多个 reducer 为根 reducer← 正确答案
  • C.合并多个 store 为一个 store
  • D.合并 action 与 reducer 参数

答案：B。combineReducers 按 key 把多个子 reducer 合并成一个根 reducer，每个子 reducer 只管自己的状态切片。它不合并组件、不合并 store，也不改变 action 的结构。

Q6. 关于 Redux 中间件，下列说法正确的是？

多选题 · mid

  • A.可以在 action 到达 reducer 前处理← 正确答案
  • B.可以增强 dispatch 函数的能力← 正确答案
  • C.可以直接修改 store 里的状态
  • D.可以用来记录日志分析流程← 正确答案

答案：ABD。中间件站在 dispatch 和 reducer 之间，可以拦截、增强 dispatch 和记日志。但中间件不直接改状态——状态只能由 reducer 计算产生，这是单向数据流的底线。

Q7. 以下哪个 effect 用于“监听某个 action”？

单选题 · mid

  • A.put 派发动作
  • B.take 等待动作← 正确答案
  • C.call 调用函数
  • D.all 并行等待

答案：B。take(type) 让 saga 暂停并等待指定类型的 action；put 是派发，call 是调用异步函数，all 是并发执行多个 effect。四个 effect 各司其职。

Q8. Redux-Saga 的 Generator 暂停机制指的是？

单选题 · hard

  • A.暂停整个浏览器线程
  • B.暂停自身等待恢复信号← 正确答案
  • C.永久退出业务处理
  • D.缓存并丢弃所有 action

答案：B。生成器 yield 只是暂停自身任务，不阻塞浏览器线程。引擎通过 next() 传回恢复信号，saga 从暂停处继续。把生成器暂停当成线程阻塞是常见误解。

Q9. Redux-Saga 常用 effect 有哪些？

多选题 · mid

  • A.take 监听动作← 正确答案
  • B.put 派发动作← 正确答案
  • C.call 调用函数← 正确答案
  • D.query 请求数据库

答案：ABC。Saga 六大常用 effect 是 take、put、call、fork、all、race。query 不是 Saga 的 effect，数据库请求应通过 call 调用专门的数据访问函数完成。

Q10. 用 Redux-Saga 处理“用户连续点击下单”的场景，正确的说法是？

多选题 · hard

  • A.takeLatest 会取消上一个未完成请求← 正确答案
  • B.takeEvery 会为每次点击启动任务← 正确答案
  • C.race 可用于设置超时竞争← 正确答案
  • D.所有 effect 都会阻塞主线程

答案：ABC。takeLatest 适合处理重复提交，新请求到来时取消旧任务；takeEvery 则每个点击都响应；race 可以跟定时器竞争实现超时。effect 是声明式的，不会阻塞主线程，D 错误。