大型项目状态管理：Zustand、Jotai 与 Redux Toolkit 深度对比与选型指南

一、先确立前提：把"服务端状态"摘出去

• 服务端状态（接口数据、缓存、轮询、失效重试）→ TanStack Query / SWR / RTK Query
• 客户端状态（UI 开关、表单草稿、选区、购物车、权限标志、向导步骤）→ Zustand / Jotai / Redux Toolkit
• 组件局部状态​ → useState / useReducer，别急着提升

二、三种心智模型的根本差异

Redux Toolkit：单一全局树 + Action/Reducer 显式流

• 状态在一个 store里，变更必须经过 dispatch(action) → reducer 纯函数。
• 强约定：slice / selector / middleware / DevTools 时间旅行。
• 优势是每一次状态变更都可追溯、可重放、可审计；代价是样板代码与心智负担。

Zustand：外部 store + hook 选择器

• 状态是模块级闭包里的普通 JS 对象，组件用 useStore(selector) 订阅切片。
• 无 Provider（也可选 Provider 做作用域隔离），可在 React 外通过 store.getState()/setState() 直接读写。
• 优势是接近裸写 JS 的直觉、极低样板、非 React 环境友好；代价是缺少强制约定，大团队容易写出风格分裂的 store。

Jotai：atom 原子图 + 依赖自动追踪

• 状态最小单位是 atom，派生 atom 通过 get 组合，组件订阅具体 atom。
• 依赖关系是隐式响应式图，atom 无人用可被 GC；异步 atom 原生接 Suspense。
• 优势是渲染爆炸半径最小、派生状态一等公民、像 useState 但全局共享；代价是 atom 多了之后需要约定命名/分组，否则散落难查。

三、大型项目关键维度对比

性能真相：微基准差距不大，关键在"订阅模型"

• Zustand 用 useStore(s => s.x) + shallow 能压住绝大多数场景，store 本身是原生对象，万级数据内存友好。
• Jotai 在"大量独立字段（表单、筛选器、仪表盘 widget）"时渲染命中面最小，但 splitAtom 渲染万行列表会堆出大量 atom 实例，反而 GC 压力上升。
• RTK 只要用 selector + 默认 reselect 记忆化，性能完全够用，慢的是"连了整个 store 却不写 selector"的写法。

四、按"大型项目画像"给选型建议

选 Redux Toolkit，当——

• 团队 20+ 人，跨多个 squad 改同一片状态，需要强制约定让陌生人也能安全 review。
• 业务有强审计需求：支付流水、权限变更、工单状态机，每一次 dispatch 都要能时间旅行回放。
• 已经深度用 RTK Query 统一管理服务端缓存，不想再引 TanStack Query。
• 代码库预期活 5 年以上、原作者会离职，"boring and predictable" 是特性不是缺点。

典型：金融科技中台、SaaS 管理后台、内部 ERP、Discord/Airbnb 类大体量产品。

选 Zustand，当——

• 新项目起步，客户端状态中等复杂度（用户会话、UI 偏好、购物车、抽屉/弹窗、多选），不想写 slice。
• 有相当比例状态读写发生在 React 之外：WebSocket 推送、埋点 SDK、路由守卫、纯 TS 领域服务。
• 团队小到中型（3–15 人），要速度也不要 Redux 的仪式感。
• 包体预算紧，或要做边缘函数/SSR 轻量客户端壳。
• 配合 TanStack Query 管服务端数据，Zustand 只装"真客户端状态"。

典型：B 端 dashboard、电商前台、Next.js App Router 下的交互岛、内部工具。

选 Jotai，当——

• 界面由大量互相独立的小状态组成：复杂表单（每字段独立校验）、可视化编辑器、表格单元格、筛选 facet、画布节点属性。
• 派生状态是核心诉求：progress = watched/total 这种"算出来"的值到处都是，声明式 atom 比手写 selector 清爽。
• 想要 Suspense 原生异步 atom，不愿手写 loading/error 三态。
• 团队接受"原子优先"心智，且愿意用 atoms/ 目录 + 命名前缀做治理。

典型：低代码搭建器、在线表格、设计工具、多步骤表单密集型 SaaS。

混合架构（生产里最常见）

五、大型项目落地时容易翻车的点

1. 不写 selector 全量订阅：const s = useStore() 在 Zustand/RTK 里都会让组件随任意字段变更重渲染，必须用选择器 + 浅比较。
2. atom 爆炸不治理：Jotai 项目前期爽，后期 atoms.ts 几百个 atom 无分组，建议按 domain/xxxAtom.ts 切文件，派生 atom 集中放 derived/。
3. 把服务端数据塞进客户端 store：除非做乐观更新桥接，否则别把接口响应存 Zustand/RTK 当缓存用——RTK Query / TanStack Query 的失效机制你手写不出来。
4. Redux 没有强制也变野：Zustand 不强制不代表不能立规，大项目里建议固定"store 按 domain 拆、action 用 set 内联、禁止组件里直接 setState 大对象"几条铁律。
5. DevTools 不接等于盲飞：Zustand 务必挂 devtools 中间件，Jotai 装 jotai-devtools，否则出问题只能静态读代码。

六、一句话决策树

• 状态多是接口数据​ → TanStack Query，别进来。
• 要审计/时间旅行/大团队强约定​ → Redux Toolkit。
• 要轻、快、能在 React 外写、中等客户端状态​ → Zustand（2026 新项目最常用默认）。
• 要字段级细粒度 + 大量派生 + Suspense 异步​ → Jotai。
• 以上都不纯粹 → 混合：服务端 Query 化，客户端按域挑 Zustand/Jotai，核心交易域留 RTK。

2026 年的"正确选型"不再是"谁取代谁"，而是承认它们分别优化了不同轴：RTK 优化可审计性，Zustand 优化开发速度与边界穿透，Jotai 优化渲染粒度与派生表达力。大型项目真正的成熟标志，是能清楚说出"这片状态为什么落在 A 而不是 B"。