授权与合规声明本文全部操作对象均为自建隔离环境与已获授权的目标涉及安全测试或以他人系统为对象的环节必须以取得合法授权为前提。未经授权的测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲技术工程实践不含任何攻击步骤、利用载荷与绕过手法请勿将文中任何内容用于非自有、未获授权的系统。第1章 为什么状态管理是前端基建1.1 全局/共享状态的必要性现代前端应用早已不是一个页面一个状态。登录用户信息、主题切换、购物车、跨页面的表单草稿这些状态需要在组件树的不同分支之间共享。如果只用 props 一层层往下传或者靠 Context 硬塞组件耦合会迅速膨胀维护成本随之上升。状态管理库的价值就是把共享状态从组件内部抽离出来变成一处可读写、多处可订阅的独立层。它不是银弹但在中大型应用里几乎是绕不开的基建。也要记住另一面不是所有状态都该进全局库。纯组件内部、不会跨组件共享的临时值用 useState 就够了强行提拔到全局反而增加不必要的复杂度。判断标准只有一条——这个状态是否真的被多个互不相关的组件共享或需要在组件卸载后仍保留。1.2 服务端状态 vs 客户端状态选库之前先分清两类状态。服务端状态指来自接口、带有缓存与失效语义的数据比如文章列表、用户资料。这类状态更适合用 React Query / TanStack Query 这类数据缓存库管理它们内置去重、后台刷新、失效重取等能力。客户端状态才是 Redux、Zustand、Jotai、Pinia 的用武之地主题、弹窗开关、本地草稿、表单临时值。把服务端状态塞进全局 store 是常见误用后面第6章会展开。// 用 TanStack Query 管理服务端状态而非塞进全局 storeimport{useQuery}fromtanstack/react-query;functionuseArticleList(){returnuseQuery({queryKey:[articles],queryFn:()fetch(/api/articles).then((res)res.json()),});}第2章 四个库各自的定位2.1 Redux含 Redux ToolkitRedux 的核心是单一数据源 纯函数 reducer 可预测的状态变更。它的强项在于可预测性与成熟的中间件生态时间旅行调试、action 日志、副作用编排redux-thunk / redux-saga在大型团队里非常有价值。截至 2026-10-25Redux 官方明确把 Redux Toolkitreduxjs/toolkit作为编写 Redux 逻辑的标准方式它用 createSlice 消除手写 action type 与不可变更新的样板。新项目若选 Redux应当直接采用 Toolkit而不是裸写 redux 核心包。Redux 真正的护城河是可审计。当业务里存在大量异步编排、需要回放每一次状态变更、要在团队间建立统一约定时它的中间件与 devtools 组合很难被轻量库替代。代价是心智负担与样板相对更高小项目用它会显得笨重。2.2 ZustandZustand 由 pmndrs 团队出品理念是用最少的样板提供全局状态。它把 store 暴露成自定义 hook无需 Provider 包裹组件中直接调用即可。对中短期、规模中等的 React 应用它几乎是最省心的默认选择上手快、TypeScript 支持好、生态中间件persist、devtools、immer开箱即用。它的代价是结构化约束偏弱超大型团队若缺乏约定store 容易组织混乱。因此用 Zustand 时建议团队自己定一份按功能切片、store 内聚的约定别让全局状态变成随意堆放的抽屉。2.3 JotaiJotai 同样出自 pmndrs走的是原子化路线。状态的基本单位是一个个 atom组件订阅某个 atom 时只有真正用到它的组件才重渲染。对于大量互相独立、又彼此派生的小状态比如复杂表单的几十个字段、筛选组合、派生视图Jotai 的细粒度响应优势明显。代价是 atom 图在大型应用里可能散落难追踪调试需要换一种心智模型。Jotai 适合状态天生就碎的场景不适合把本来聚合良好的领域状态硬拆成几十个原子。// Jotai以 atom 为基本单位按需派生 import { atom } from jotai; const userNameAtom atom(); const statusAtom atom(idle); // 派生 atom基于已有 atom 计算不额外触发重渲染 const greetingAtom atom((get) { const name get(userNameAtom); return name ? 你好${name} : 请登录; });2.4 PiniaPinia 是 Vue 官方状态库也是 Vuex 的继任者。截至 2026-10-25在 Vue 3 项目中它被官方推荐为默认状态方案。API 贴近组件写法类型可自动推断支持 devtools、模块化拆分与热更新。只要是 Vue 技术栈几乎不必纠结——选 Pinia 即可。它不属于 React 生态选型时第一步就是先定框架。对 Vue 团队来说Pinia 几乎不存在要不要选的问题更多是怎么组织 store 文件的工程问题。// PiniadefineStore 定义一个 storeimport{defineStore}frompinia;exportconstuseCounterStoredefineStore(counter,{state:()({counter:0,status:idle}),getters:{doubleCounter:(state)state.counter*2,},actions:{increment(amount:number){this.counteramount;},},});第3章 对比维度3.1 包体积 / 样板代码 / TS 支持 / 调试体验 / 学习曲线下面这张表从五个常被拿来比较的维度做横评。注意包体积数字会随版本变化下表标待验证以各库官方发布为准维度评分是相对主观的归类不是定量结论。维度Redux ToolkitZustandJotaiPinia包体积gzip待验证较大极小很小很小样板代码量中等极少少少TypeScript 支持优秀优秀优秀优秀调试体验强时间旅行一般需中间件一般强Vue devtools学习曲线较陡平缓平缓但需换心智平缓第4章 选型决策表4.1 按框架规模复杂度选型判据不是谁更好而是框架 项目规模 状态复杂度。下面给出场景到推荐的映射。注意最后一列是为什么帮你在边界场景里自己推演而不是死记结论。场景推荐理由Vue 技术栈项目Pinia官方默认零纠结React 中大型团队、复杂状态流、强调试需求Redux Toolkit可审计、生态成熟React 中小型项目、追求轻量省心Zustand样板少、上手快React 大量独立/派生小状态、细粒度重渲染Jotai原子化、按需响应服务端数据接口缓存TanStack Query缓存失效语义内建纯 UI 局部状态useState Context无需引入依赖——Vue 技术栈项目PiniaReact 中大型团队、复杂状态流、强调试需求Redux ToolkitReact 中小型项目、追求轻量省心ZustandReact 大量独立/派生小状态、细粒度重渲染Jotai服务端数据接口缓存TanStack Query纯 UI 局部状态useState Context第5章 代码对比5.1 Redux Toolkit 一个 slice下面的示例用 createSlice 定义一个计数器 slice。⚠️ 代码待验证请以官方文档为准。import{createSlice,PayloadAction}fromreduxjs/toolkit;interfaceCounterState{counter:number;status:string;}constinitialState:CounterState{counter:0,status:idle};constcounterSlicecreateSlice({name:counter,initialState,reducers:{incrementByAmount(state,action:PayloadActionnumber){state.counteraction.payload;state.statuschanged;},reset(state){state.counter0;state.statusidle;},},});exportconst{incrementByAmount,reset}counterSlice.actions;exportdefaultcounterSlice.reducer;5.2 Zustand 一个 store下面用 create 定义一个同等语义的 store。⚠️ 代码待验证请以官方文档为准。import{create}fromzustand;interfaceCounterStore{counter:number;status:string;incrementByAmount:(amount:number)void;reset:()void;}exportconstuseCounterStorecreateCounterStore((set)({counter:0,status:idle,incrementByAmount:(amount)set((state)({counter:state.counteramount,status:changed,})),reset:()set({counter:0,status:idle}),}));状态管理选型速查卡把第3、4章的对比与决策整理成一张卡。放在资料包里扫码即可获取第6章 常见误用6.1 把服务端状态塞进全局 store接口数据自带缓存、失效、并发语义用全局 store 手动维护容易写出重复请求与陈旧数据。交给 TanStack Query 这类库比自己造轮子稳得多。一个简单判据这份数据来自网络、会过期、会被多个地方读取——它八成是服务端状态。6.2 过度拆分原子Jotaiatom 拆得太碎派生关系网会难以追踪调试时找不到状态来源。按业务边界而非每个字段一个 atom来组织必要时用派生 atom 聚合。6.3 在 Redux 里写副作用不中规中矩把异步、副作用直接写进 reducer 会破坏可预测性。应走 redux-thunk / createAsyncThunk或把副作用放到中间件保持 reducer 纯函数。一旦 reducer 里出现 await 或随机数调试器和时间旅行就失去意义问题会很难复现。误用表现建议服务端状态进 store重复请求、数据陈旧用 TanStack QueryJotai 原子过碎调试困难、关系网混乱按业务边界聚合Redux 副作用乱写状态不可预测走 thunk / 中间件第7章 迁移与渐进策略7.1 不要一次性重写状态层牵一发动全身。把整库替换当成一次大重写风险与回归成本都高。更稳妥的是先在小模块试点新方案验证心智模型与团队接受度。观察两周开发者是否顺畅、渲染性能是否达标、调试是否还方便——再决定是否推广。7.2 新老并存平滑过渡现代库大多能并存Zustand 与 Jotai 可通过桥接库协同Redux 也能逐步把 reducer 迁移到 createSlice。关键是在边界处明确哪块状态归谁避免两套状态互相抢源。迁移过程中保留清晰的接口层让组件不直接依赖某一套实现后续再换就更从容。前端选型决策树把第4章的决策表扩展成一张流程图。放在资料包里扫码即可获取附表 A本文引用事实与出处对照表事实出处本文位置Redux Toolkit 是 Redux 官方推荐的写法Redux 官方文档 redux.js.org / redux-toolkit.js.org第2章 2.1Pinia 是 Vue 官方状态库继任 VuexPinia 官方文档 pinia.vuejs.org 与 Vue 官方资料第2章 2.4Zustand 由 pmndrs 团队维护GitHub pmndrs/zustand第2章 2.2Jotai 由 pmndrs 团队维护GitHub pmndrs/jotai第2章 2.3各库包体积 gzip 数值待验证以各库官方发布为准第3章 3.1具体版本号待验证全文附表 B术语速查表术语含义单一数据源Redux 的核心原则整个应用状态存于一棵 state 树reducer接收旧状态与 action、返回新状态的纯函数atomJotai 中状态的最小单位可独立订阅与派生sliceRedux Toolkit 中按功能划分的一块状态与逻辑store状态容器提供读写与订阅能力服务端状态来自接口、带缓存与失效语义的数据写在最后这篇用到的资料写这篇文章时整理了前端工程化的选型方法顺手也整理了几份配套的东西大模型学习路线从基础到落地的整套路径图Claude Skills 全指南知识库搭建与技能编排实战LangGraphMCP 智能体实战视频从 0 到 1 跑通一个智能体资料是我自己整理的放在下面这个码上扫码即可获取资料较多建议先看「全套 AGI 大模型学习路线」再挑一个实战项目跟练。