Context / Zustand / Redux 如何选型

卷三过半：第 17 篇把状态分成「客户端」与「服务端」两类，第 18 篇 Zustand、第 19 篇 Redux Toolkit 接管客户端状态。三件工具（加上第 15 篇的 Context）都摆上了货架，工作里被问得最多的却从来不是「怎么用」，而是「我的项目该用哪个」。回答之前，先把三者的本质摆平——它们对应后端三种你天天打交道的形态：

没有高下，只有形态。选型问题其实是两个问题：你的数据更新频率多高？要不要变更留痕？带着这两个问题看下一站。

Context：低频配置的只读广播

主场：主题与暗色模式、语言、当前登录人、组件库的全局配置——启动定一次、顶多变几次的「环境值」。禁区一：高频变更，输入框每敲一个字符就广播一次，全树消费者陪跑。禁区二：把它当大型应用唯一状态方案，很快退化成 Provider 嵌套地狱加全局重渲染风暴。口诀：一年变一次用 Context，一秒变一次快逃。

Zustand：中小型客户端状态的事实标准

主场：购物车、侧边栏开合、当前 tab、跨路由存活的操作草稿——更新频繁、但每次只影响少数组件的客户端状态。禁区一：服务端数据，接口列表塞进 store，缓存失效、去重、竞态全要手搓（第 17 篇的分野，第 33 篇的正解）。禁区二：selector 里返回字面量新对象，重渲染失控（第 18 篇的坑）；超大团队需要强制规范时，「自由」管不住人。

Redux Toolkit：大团队与强规范的主场

主场：变更需要审计与回放（撤销重做、协同编辑）、状态联动复杂、超大团队统一写法、依赖中间件生态。禁区：三五个组件共享一个开关也建 slice，样板税远超收益；小项目为了简历上写「会 Redux」而上，面试官问一句 reducer 纯度就露馅。

反模式速查，对照自查：

把三个工具和「都不选」排成一棵树，自上而下问，命中即停。注意：大多数项目会在第 2、3 问就停下——这不是偷懒，是正确。

最后修正一个常见误解：选型不是开工第一天就要锁死的「架构决策」，而是跟着功能长出来的。今天一个组件自己用——local state；明天第二个组件要共享——状态提升（第 14 篇）；后天提到三层之外——Zustand 十行迁完；大后天要审计回放——再迁 RTK。每一级的迁移成本都不高，尤其 Zustand → RTK：selector 换 useSelector，函数调用换 dispatch，状态实体几乎原样搬运。既然逐级上不贵，「一步到位」就更没必要。

误区一：一上来就 Redux

样板税先交齐，纪律却未必建立：没有 code review 兜底时，reducer 里照样塞请求、action 命名照样放飞。「用了 Redux」和「有了可预测性」之间，隔着一整套团队规范。等规范需求真的出现再引入，目标清晰，迁移也有方向——这是对第 19 篇「纪律买什么」最诚实的回答。

误区二：把服务端数据塞进全局 store

第 17 篇的分野值得再念一遍：服务端状态自带一套缓存协议——新鲜度、失效、去重、重试、乐观更新。TanStack Query 把这些全做好了（第 33 篇）；塞进 Zustand 或 Redux，等于手写一个残缺版缓存中间件，还把两类状态搅成一锅，最后谁也说不清哪份数据可信。

收尾给一张「常见状态归位表」，可以直接贴进团队文档：

选型的终点不是「挑出一个赢家」。真实的中型项目里，几种工具几乎总是同时在场——各管各的状态，谁也不抢谁的活。看一个电商后台的布局组件，每一处状态都标注了它在决策树上命中的那一问：

import { createContext, useContext, useState } from "react";
import { create } from "zustand";

// 第 3 问命中：主题这类低频、近乎只读的全局配置 → Context
const ThemeContext = createContext<"light" | "dark">("light");

// 第 5 问命中：要跨路由存活的布局偏好 → Zustand
const useLayoutStore = create<{ collapsed: boolean; toggle: () => void }>()(
  (set) => ({
    collapsed: false,
    toggle: () => set((s) => ({ collapsed: !s.collapsed })),
  })
);

function Dashboard() {
  // 第 2 问命中：只有本组件用的搜索词 → local state
  const [keyword, setKeyword] = useState("");

  const theme = useContext(ThemeContext);
  // 订阅只挑需要的字段：侧边栏折叠态变了，才重渲染
  const collapsed = useLayoutStore((s) => s.collapsed);

  // 第 1 问命中：订单列表是服务端数据，不进任何 store
  // → useQuery({ queryKey: ["orders", keyword], ... })，第 33 篇展开

  return (/* 侧边栏、搜索框、订单表：各取所需，略 */);
}

五种状态、四个答案，没有一种工具「垄断」这个项目：Context 不碰订单列表，Zustand 不碰搜索词，谁也没越界。注意最后一行——服务端数据连登场的机会都没有，红线在写第一行代码时就划好了。这才是决策树的正确用法：不是面试背书的流程图，而是每天落笔时的路标——每写一份新状态，先过一遍五问，归属自然浮现。