想象你的App是一个四世同堂的大家庭：导航组件是爷爷、商品列表是爸爸、购物车是妈妈、用户头像和消息角标是兄弟姐妹。全家人都想知道“我买了几件东西”“账号有没有登录”“购物车里总价多少”这些事儿。如果每个人都只盯着自己的小本子记，消息就对不上——爸爸改单价时，妈妈那里的总价还停留在昨天。于是全家需要一本“公共记事本”来同步信息，这就是状态管理（State Management）。 但“公共记事本”也有人各有志：有的家庭喜欢银行金库式的严谨账本（Redux），每笔账都要走柜台填表单；有的家庭爱用会魔法感应的共享备忘录（MobX），写上一条全家自动更新；还有的家庭图省事，直接在冰箱上贴便利贴（Zustand），想贴就贴、想撕就撕。三本记事本，三种哲学。这篇教程会带你挨个翻看，搞懂它们各自的分工和脾气，再像挑家具一样，帮你给团队和项目选到最趁手的那一本。

岗位关联

对AI从业者来说，掌握RN状态管理不只是会调API——它是理解前端“全局数据流”设计的万能钥匙，无论你未来面向大模型应用还是Agent工作台，这套架构思维都能直接复用。

目录
  1. 可视化演示
  2. 状态管理初识
  3. Redux核心
  4. MobX响应式
  5. Zustand魅力
  6. 方案设计PK
  7. 选型实战建议
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

对比Redux单向数据流、MobX响应式追踪和Zustand极简方案三种状态管理架构，交互切换观察各方案的状态更新机制与数据流向差异。

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

'+captions.redux+'

状态管理初识

一个家庭最怕什么？消息走漏。爸爸在菜市场改了晚饭菜单，厨房里的妈妈不知道；哥哥买了电影票，妹妹还在群里问“今晚干嘛”。组件世界也一样：页面A更新了用户积分，页面B还显示旧数据。大家各记各的账，就会得出矛盾的结论。React Native的单组件状态（useState）只能管自己家门口的小黑板，真正需要全家协作的“状态”却散落各处——传参传得晕头转向，回调嵌得像千层饼。状态管理，就是给全家装上一块统一口径的公共记事本，谁写了什么、谁要读什么，都在这本子上对齐。

公共记事本的价值不只在于“让消息不丢”，更在于让行为可预测。当夫妻约定“今晚谁做饭”以记事本为准时，吵架就少了；当组件约定“数据一律从Store读”时，Bug就少了。React Native生态长期实践后，沉淀出三大主流方案：Redux、MobX、Zustand。它们像三种性格的管家：Redux严谨刻板，每个操作都要按流程来；MobX通晓魔法，让数据自己会说话；Zustand随性直接，怎么省事怎么来。

组件之间的通信成本会随数量增长而爆炸。如果有 $n$ 个组件两两传话，就需要 $\frac{n(n-1)}{2}$ 条通道；一旦改成“所有人都到公共记事本上读写”，通道数骤降为 $n$ 条，这就是状态管理最朴素的数学理由。

回想一下这个概念：公共记事本把“谁和谁两两传话”的混乱小巷，改造成了“人人通向广场”的单行大道。状态越多、组件越杂，这条大道就越值钱。

Channels=n(n−1)2→状态集中管理n\text{Channels} = \frac{n(n-1)}{2} \xrightarrow{\text{状态集中管理}} n
当组件多起来时，两两耦合的通信路径呈平方级爆炸，状态管理把每条路径都收编到“记事本”上，让复杂度线性可控。
  1. 两两通信的计算$n$ 个组件若互相直接传值，每两个组件之间需要一条通道，所以路径数是组合数 $C(n,2)$。
    C(n,2)=n(n−1)2\displaystyle C(n,2) = \frac{n(n-1)}{2}
  2. 集中后的简化所有组件只与中央Store通信，每个组件一条线，所以总通道数从平方级降为线性。
    Channelscentral=n\displaystyle \text{Channels}_{\text{central}} = n

Redux核心

Redux的哲学像银行金库——严谨、可追溯、一口唾沫一个钉。顾客取钱不许自己进保险库摸，必须填取款单（Action）、交到柜台（dispatch）、柜员核验并记账（Reducer）、再把新余额单盖章送回（NewState）。任何人任何时候都拿得到“当前账户流水”，出了差错按单查账一目了然。

核心技术要点是单向数据流：UI发起Action → dispatch到Reducer → 生成NewState → 通知UI更新。这个环不会短路也不会逆流，所以调试时你可以逐个环节回放。Redux同时坚持不可变更新（immutable update）——账本不许用橡皮擦改，必须抄一本新账本再划掉旧账。这不是古板，而是为了让React能通过引用对比快速判断“数据变没变”。

Redux的核心公式可以浓缩为一行：

回到比喻：金库之所以安全，靠的不是蛮力，而是流程纪律。Redux用严格的单向流程和非破坏性更新，换来了惊人的可预测性——这对大型团队尤其宝贵，因为每个人的修改都能像审计流水线一样被追溯。缺点是流程繁琐：填单、交单、核单，哪怕加一勺糖也要走全套。

NewState=Reducer(PrevState,Action)\text{NewState} = \text{Reducer}(\text{PrevState}, \text{Action})
Redux把状态更新定义成一个纯函数的输入输出：给旧状态和动作，就稳定返回新状态，绝无副作用。
  1. PrevState（旧账本）更新前那一版完整状态，比如购物车里的 {items: [...], total: 0}。
    PrevState={items:[…],  total:0}\displaystyle \text{PrevState} = \left\{ \text{items}: [\ldots],\; \text{total}: 0 \right\}
  2. Action（取款单）描述“想干什么”的最小对象，比如 {type: 'ADD_ITEM', payload: {id: 1}}。关键约定：type 必填且唯一，Redux靠它匹配分支。
    Action={type:string,  payload:any}\displaystyle \text{Action} = \left\{ \text{type}: \text{string},\; \text{payload}: \text{any} \right\}
  3. Reducer( )（柜员记账）一个纯函数，内部用 if/switch 根据 Action.type 匹配逻辑，返回全新对象。
    Reducer(s,a)={{…s,  total:s.total+a.payload}a.type=’ADD_ITEM’sotherwise\displaystyle \text{Reducer}(s, a) = \begin{cases} \{ \ldots s,\; \text{total}: s.\text{total} + a.\text{payload} \} & a.\text{type} = \text{'ADD\_ITEM'} \\ s & \text{otherwise} \end{cases}
  4. NewState（新账本）Reducer 的返回值，替换旧状态并触发组件渲染。
    NewState=Reducer(PrevState,Action)\displaystyle \text{NewState} = \text{Reducer}(\text{PrevState}, \text{Action})

MobX响应式

如果说Redux是银行金库，MobX就是家里的魔法共享备忘录——不用填单子，只要某个人改了备忘内容，所有盯着这块内容看的人都会自动收到更新。它打通了一条“数据—界面”的隐形光线：你改边，我变边，全自动。

原理核心是可观察数据（Observable）。把一个普通对象变成被监视的状态源后，所有在“副作用函数”里读到的字段都会被悄悄记录下来；一旦字段变化，MobX像经验丰富的管理员立刻翻开登记册，找出所有依赖它的函数精准通知。这种技术叫依赖收集（dependency collection），源于响应式编程。computed派生值则像“购物车总价”，它本身不存数据，却根据商品价格实时算出。

这魔法备忘录最妙的一点是：开发者几乎不手写连接代码。状态改了，界面自己就跟着改。代价是“魔法”需要理解和信任——如果不熟悉 computed 和 action 的边界，容易在过大依赖图中迷失。但小团队和追求迭代速度的团队，往往爱死这种“写完数据就收工”的爽快。

Reaction=∑dependenciesObserve(Observablei)→changeNotify(AutoRunj)\text{Reaction} = \sum_{\text{dependencies}} \text{Observe}(\text{Observable}_i) \xrightarrow{\text{change}} \text{Notify}(\text{AutoRun}_j)
MobX把“状态变化后谁该更新”这件事从手动 notify 变成了自动订阅：一次依赖收集，终身精准推送。
  1. Observable（被盯梢的状态）标记数据为“可观察”，比如 observable({count: 0})。
    obs=observable({count:0})\displaystyle \text{obs} = \text{observable}(\{ \text{count}: 0 \})
  2. AutoRun（自动警员）执行一次函数，同时收集它读取过的所有 obs 字段，形成依赖表。
    autoRun(f)→deps={count}\displaystyle \text{autoRun}(f) \rightarrow \text{deps} = \{ \text{count} \}
  3. Change（值班变动）当 count 被修改时，注册表里所有依赖它的 Reaction 会被标记为“待执行”。
    obs.count++→Notify(deps)\displaystyle \text{obs}.\text{count}++ \rightarrow \text{Notify}(\text{deps})
  4. Reaction（连锁反应）MobX异步批量触发所有界面更新，完成“改一处、动一片”的自动同步。
    Reaction=Execute(f)\displaystyle \text{Reaction} = \text{Execute}(f)

Zustand魅力

Zustand要回答的问题是：都 2024 年了，状态管理能不能像叫外卖一样简单？答案就一句话：是的。它像冰箱上随手可贴的便利贴——想记录时，抄起 create 就是一张新贴纸；想修改时，直接 set 改掉；想读取时，用 hook 一行拿走。没有 Provider 层层包裹，没有 Reducer 模版工程，只有一个 store + 两个方法（get/set）+ 一个 hook。

技术上，Zustand 把 store 建在 React 之外，用订阅机制驱动组件更新。你不需要把整个 <StoreProvider> 挂到 App 根部，而是需要哪个组件，就在哪个组件里 useStore(s => s.count)。它甚至可以直接在 store 里写异步逻辑、写中间件，轻量得让人怀疑这是否太简陋——但实际跑起来，性能和开发体验反而出奇地好。

如果说Redux是写小说要列大纲，Zustand就是“想到哪儿写到哪儿”的微博。它尊重“快速上线”的真实需求，把状态管理的仪式感降到了最低。对中大型项目，只要约定好 store 文件组织方式，Zustand的简洁反而是生产力——因为它减少了所有“管道代码”的阅读负担。

Store=create(initialState)(set,get)\text{Store} = \text{create}(\text{initialState})(\text{set}, \text{get})
Zustand用一条create命令就完成了“创建store + 定义读写方法”两步操作，零模板、零Provider。
  1. create(initialState)传入一个函数，函数接收 set 和 get 两个工具后返回初始状态。
    create(f)wheref(set,get)→state\displaystyle \text{create}(f) \quad \text{where} \quad f(\text{set}, \text{get}) \to \text{state}
  2. set(partial)像便利贴重写，直接传入部分状态进行合并更新。
    set({count:get().count+1})\displaystyle \text{set}(\{ \text{count}: \text{get}().\text{count} + 1 \})
  3. useStore(selector)组件通过 hook 选择自己关心的切片数据，没有多余渲染。
    const count=useStore((s)⇒s.count)\displaystyle \text{const count} = \text{useStore}((s) \Rightarrow s.\text{count})

方案设计PK

现在我们已经见过三本风格迥异的记事本：厚重账本、魔法备忘录、便利贴。该怎么选？先来一场“家庭记事本产品力大PK”。我们比三轮：学习曲线、代码量、维护体验。

学习曲线：Redux最陡——新手要先理解Action、Reducer、dispatch、不可变更新的全套概念，常常被“为什么我不能直接改状态”劝退。MobX中等——响应式概念直观，但 computed/action/autorun 的边界需要品。Zustand最平——只需三个API就能上手，一小时包会。

代码量：同样的“计数器”需求，Redux需写 action 类型、action creator、reducer、store 至少四个文件；MobX只需一个 class Store { count = 0; increment() { this.count++ } }；Zustand只用几行 create。代码量直接决定了团队认知负担和重构成本。

性能与调试：Redux的不可变更新天然利于引用对比，配合 Redux DevTools 可以时间旅行调试；MobX的细粒度追踪很高效，但过度包装容易让优化无从下手；Zustand的selector机制能精准跳过无关更新，调试时直接查 store 即可。没有绝对赢家，只有匹配度问题。

这场PK没有标准答案，只有“适合”两字。就像有人爱精装记账，有人爱随手贴条——重点不是谁更好，而是你家是谁在管家。工具服务于人，而不是人服务工具。

Score=w1⋅学习成本−1+w2⋅代码量−1+w3⋅维护体验\text{Score} = w_1 \cdot \text{学习成本}^{-1} + w_2 \cdot \text{代码量}^{-1} + w_3 \cdot \text{维护体验}
选型不是找“最好的”，而是找“权重最适合自己的”——小项目重学习成本，大项目重维护体验。
  1. 学习成本项权重 $w_1$ 表示团队对“上手快”的重视程度，值越大越偏向简单方案。
    w1⋅1学习成本\displaystyle w_1 \cdot \frac{1}{\text{学习成本}}
  2. 代码量项权重 $w_2$，代码越少该项越大，对应开发效率和可读性。
    w2⋅1代码量\displaystyle w_2 \cdot \frac{1}{\text{代码量}}
  3. 维护体验项权重 $w_3$，体现长期运行中的调试便利、可扩展性，是直觉分。
    w3⋅维护体验\displaystyle w_3 \cdot \text{维护体验}

选型实战建议

如果一个爸爸买菜时随手贴条，另一个爸爸非要去银行金库给萝卜记账，前者太随意、后者太夸张。真正聪明的主妇会看规模和家人习惯：三口之家贴条足够；家族聚餐宴请宾客才需要正规账本。

把原则翻译成工程语言：小项目（5 个页面以内、状态少） 直接上 Zustand，省时省力；中项目（10 页面左右、有实时联动数据） MobX 的自动派生能省掉大量手动同步代码；大项目（多团队协作、需要严格审计和回放） Redux 的流程纪律和周全生态（DevTools、中间件、社区方案）更稳。这只是起点，团队熟练度才是决定性变量——让一个熟 Redux 的老团队去写 Zustand，效率不会翻天覆地，反而平添摩擦。

成本账也要算清楚：Redux 的模板代码虽多，但出问题时排查路径清晰；MobX 的简洁背后是排障时要理解依赖图；Zustand 的灵活则要求团队有良好的 store 分区习惯。把这些写进团队决策，比拍脑袋选型更接地气。

记住，选笔记本身只是开始：约定store目录结构、命名规范、数据流文档，这些让三种工具都能发力。说到底，状态管理的终极目标是让全家信息透明、和谐运转，选哪本记事本，回到一个朴素的判断：用得顺手、看得明白、改得放心。

---

Decision=arg⁡max⁡m∈{Redux,MobX,Zustand}Suitability(m∣规模,偏好,成本)\text{Decision} = \arg\max_{m \in \{\text{Redux}, \text{MobX}, \text{Zustand}\}} \text{Suitability}(m \mid \text{规模}, \text{偏好}, \text{成本})
选型本质是一个在约束条件下求最大化的决策过程：在“项目规模、团队偏好、长期成本”三个约束里，挑一个综合匹配度最高的方案。
  1. argmax（挑最大）在三个候选中找到评估值最高的那一个。
    arg⁡max⁡m\displaystyle \arg\max_{m}
  2. Suitability（适合函数）该函数综合输入“规模、偏好、成本”并给每个打分。
    Suitability(m∣规模,偏好,成本)\displaystyle \text{Suitability}(m \mid \text{规模}, \text{偏好}, \text{成本})

AI 应用场景

React Native 智能助手的全局数据中枢

阶段：数据处理与状态同步

解决的问题：AI助手App中，用户会话历史、模型回复流式输出、设置项等全局状态分散在多个组件中，传统手动props逐层传递极易错乱，流式回复每来一帧Tokenizer就要更新UI，状态延迟会毁掉对话体验。

具体案例：某购物App内置AI穿搭助手，采用 Zustand 管理会话流：useStore 直接订阅 streamingMessage 切片，AI新字词到达时 store 秒级更新组件，同时用户手动修改偏好也会立即合并进上下文。得益于Zustand的selector机制，无关组件零重渲染。

数据标注平台的Redux审计流

阶段：数据处理与模型训练前的数据治理

解决的问题：数据标注平台需要严格记录“谁在何时改了什么标注”，如果状态任意可改，错误标注无法追溯。

具体案例：某医疗影像标注平台用 Redux 管理标注快照流：每次框选、修改标签都派发 Action，红帽审核员可通过 Redux DevTools 的时间旅行回放标注全流程，定位AI误标源点。

Python 演示

python61 行
# 模拟三种状态管理思路的最小实现from functools import reduce # ---------- Redux 风格 ----------def reducer(state, action):    if action['type'] == 'increment':        return {'count': state['count'] + 1}    if action['type'] == 'decrement':        return {'count': state['count'] - 1}    return state def create_store(initial):    state = initial    def dispatch(action):        nonlocal state        state = reducer(state, action)        return state    def get_state():        return state    return dispatch, get_state dispatch, get_state = create_store({'count': 0})dispatch({'type': 'increment'})dispatch({'type': 'increment'})print('Redux state:', get_state()) # ---------- MobX 风格 ----------class ObservableBox:    def __init__(self, value):        self._value = value        self._listeners = []    def set(self, new_value):        if self._value != new_value:            self._value = new_value            for fn in self._listeners:                fn(self._value)    def get(self):        return self._value    def observe(self, fn):        self._listeners.append(fn) box = ObservableBox(0)box.observe(lambda v: print('MobX auto-updated:', v))box.set(box.get() + 1)box.set(box.get() + 1) # ---------- Zustand 风格 ----------def create_simple_store(initial_state):    state = dict(initial_state)    def set(partial):        nonlocal state        state.update(partial)    def get():        return state    api = {'set': set, 'get': get}    return api store = create_simple_store({'count': 0})store['set']({'count': store['get']()['count'] + 1})store['set']({'count': store['get']()['count'] + 1})print('Zustand state:', store['get']())
目的：用 60 行 Python 复刻了 Redux 的纯函数 Reducer、MobX 的观察者模式、Zustand 的 set/get 极简 API，让小白直观看到三种设计思想的本质差异。
  1. def reducer(state, action)Redux 的柜员：根据 action.type 决定如何更新状态，且绝不修改原对象。
  2. state.update(partial)Zustand 的 set 本质：用部分更新合并新状态，简单直接。
  3. box.observe(lambda v: ...)MobX 的自动追踪：状态一变化，所有观察者自动收到通知。
  4. nonlocal state闭包保存状态，模拟外部 Store 的“全局内存”。

常见误区

误区初学者常以为 Redux 天生不会异步，必须立刻安装中间件，否则无法发起网络请求。

正解Redux 本身只管理同步纯函数更新，但异步逻辑本质是“先发一个请求Action，拿到结果再发一个完成Action”。中间件只是帮你把这段流程组织得更优雅，不是必需品——你完全可以在组件里用 async/await 获取数据后 dispatch。就像金库取钱可以自己先排队，不一定非要请中介。

为何常见：教程大多以 Redux 全家桶（含中间件）为默认模板，导致小白误以为“缺了中间件等于不能用Redux”。

误区觉得只要声明了 observable，所有用到它的组件都会精准更新，性能躺着就最优。

正解MobX 确实做依赖收集，但不加思考地共享大对象、在 render 里啃全集数据，依旧会造成多余渲染。computed 派生值的缓存也需要合理设计。好比魔法备忘录虽然会自动同步，但如果你把整本字典都设成“被盯梢”，收件箱一样会爆。优化依然需要理解依赖粒度。

为何常见：“响应式”三个字给人“全自动”的错觉，忽略了它是建立在依赖图之上的自动。

误区规模一大就认为 Redux 才是唯一正解，Zustand 是玩具。

正解Zustand 可扩展性其实很强——你可以拆分多个 store、用中间件做持久化、配合 TypeScript 获得极佳类型提示，还能无缝接入 devtools。大项目真正的难点是状态边界划分，这跟工具关系不大。好比便利贴，只要分门别类贴得好，厨房管理几百张便签也不是问题。

为何常见：Redux 在大厂宣传中根深蒂固，让“重量级方案 = 大项目标配”成了直觉。

误区认为 Redux 每次更新都要 `JSON.parse(JSON.stringify(state))` 来保证新引用。

正解不可变更新指不修改原对象，但可以通过展开运算符/Object.assign 仅复制变化层，其他层级保留引用。深拷贝全量对象既浪费内存，又会丢失引用对比带来的性能优势。好比账本只抄写改动的那一页，其他页原样保留，而不是整本重抄。

为何常见：对“不可变”字面理解过深，忘了它的目的是可预测更新，而不是机械重做所有数据。

面试题

Q1. Redux 中，唯一能修改 State 的途径是什么？

单选题 · easy

  • A.直接调用 store.setState 方法
  • B.派发 Action 给 Reducer← 正确答案
  • C.在组件中修改 state 属性
  • D.在 Reducer 外修改 state 引用

答案：B。Redux 强制单向数据流，State 只能由 Reducer 纯函数根据 Action 生成新状态。B 正确。A 是 Zustand 的写法；C、D 违背不可变更新原则，属于直接篡改状态。

Q2. 下列哪个方案的核心思想是“依赖收集 + 自动追踪”？

单选题 · easy

  • A.Redux
  • B.MobX← 正确答案
  • C.Zustand
  • D.Context API

答案：B。MobX 通过 observable 数据的依赖收集实现自动精准更新。Redux 是单向数据流，Zustand 是极简订阅，Context 是 React 内置的跨层传值机制，均不具备自动追踪特性。

Q3. Redux 中为什么要求 Reducer 必须是纯函数？

单选题 · mid

  • A.因为纯函数性能更高
  • B.为了支持时间旅行调试和可预测性← 正确答案
  • C.因为 JavaScript 缺少不可变数据结构
  • D.为了兼容 React Native 编译

答案：B。纯函数保证了相同输入必定产生相同输出，无副作用，从而让状态更新可预测、可回放。B 正确；纯函数不一定性能更高（A），也不因 JS 缺少不可变结构（C），更与 RN 编译无关（D）。

Q4. 在 MobX 中，computed 派生值的主要特征是什么？

单选题 · mid

  • A.每次访问都重新计算，绝无缓存
  • B.依赖数据不变时缓存结果，变化时自动重算← 正确答案
  • C.必须在组件外手动调用才能生效
  • D.只能用于布尔类型判断

答案：B。computed 的派生值在依赖不变时直接返回缓存，依赖变化才重算，就像购物车总价随商品价格自动刷新。A 说反了；C 不准确，computed 可被自动追踪；D 限制太窄。

Q5. Zustand 与 Redux 相比，最突出的设计差异是什么？

单选题 · mid

  • A.Zustand 不支持异步操作
  • B.Zustand 无需 Provider 包裹，store 独立于组件树← 正确答案
  • C.Zustand 只能管理局部状态
  • D.Zustand 强制使用不可变更新

答案：B。Zustand 的 store 基于外部单例，组件通过 hook 订阅，无需在根部套 Provider。B 正确；Zustand 支持异步（A 错），可管理全局状态（C 错），set 内部虽是合并但不断言不可变（D 错）。

Q6. MobX 中 action 的作用是什么？

单选题 · mid

  • A.强制所有状态修改都必须同步
  • B.统一修改可观察状态的入口，便于追踪事务← 正确答案
  • C.替代 computed 做派生计算
  • D.让状态变成不可变数据

答案：B。action 将一组状态修改包装成一个事务，便于 MobX 批量通知和调试追踪。B 正确；action 不改同步性要求（A），与 computed 职责不同（C），也不负责不可变（D）。

Q7. 以下哪些场景更适合选择 Redux？（多选）

多选题 · mid

  • A.多团队协作的大型项目需要严格审计← 正确答案
  • B.需要时间旅行调试快速定位数据问题← 正确答案
  • C.三五人小团队追求一周内上线
  • D.需要完善的中间件生态← 正确答案

答案：ABD。Redux 的流程纪律、DevTools 时间旅行和成熟中间件生态适合大型且需审计的场景，A、B、D 正确。C 描述的快速上线场景更适合 Zustand 或 MobX，Redux 的样板代码反而拖慢节奏。

Q8. 关于不可变更新的说法，正确的有哪些？（多选）

多选题 · mid

  • A.新状态应尽量复用未变化部分的引用← 正确答案
  • B.每次更新必须深拷贝所有数据
  • C.有利于 React 的快速 diff 优化← 正确答案
  • D.只在 Redux 中需要，MobX 不需要

答案：AC。不可变更新通过扩散运算符只复制变化层，复用深层引用（A 对）；深拷贝全量是错误做法（B 错）；新引用让 React 通过 Object.is 快速跳过不变子树（C 对）；MobX 也鼓励在 action 中一致地更新状态（D 错）。

Q9. Zustand 的 selector 机制最核心的优化收益是什么？

单选题 · hard

  • A.减少网络请求次数
  • B.精准控制组件只订阅关心的状态切片，避免无关重渲染← 正确答案
  • C.让 store 自动持久化到本地存储
  • D.消除所有闭包内存泄漏

答案：B。useStore 传入 selector 后，只有选中切片变化才触发组件重渲染，这是 Zustand 高性能的关键。B 正确；selector 与网络（A）、持久化（C）无关，也不能消除全部内存问题（D）。

Q10. 某中型 RN 项目状态联动频繁，团队新手居多，希望减少样板代码，下列哪些选择是合理的？（多选）

多选题 · hard

  • A.直接拥抱 Zustand 降低学习成本← 正确答案
  • B.选择 MobX 利用自动追踪减少手动同步← 正确答案
  • C.强制使用 Redux 并用中间件解决一切问题
  • D.先小规模试点再逐步统一方案← 正确答案

答案：ABD。新手团队优先选低学习成本方案，Zustand 和 MobX 都符合（A、B 对）。C 机械套用重型方案会拖累迭代。D 的灰度策略更稳妥，先试点验证再推广。故答案 0、1、3。