1. 从useState到useReducer为什么你需要第二个状态方案这两年我在跟不少前端开发者交流时发现一个很有意思的现象很多人写 React 组件一遇到复杂状态就下意识地堆 useState结果状态逻辑越写越乱组件层级越来越深到最后连自己都理不清状态是怎么变化的。我在实际项目里也踩过这个坑后来认真把 useReducer 吃透之后再看那些状态复杂的需求思路完全不一样了。先说不绕弯子的结论useReducer 是 React 提供的一个用于管理复杂状态逻辑的 Hook它的核心思想是把状态的更新规则从组件里抽离出来集中到一个纯函数里统一管理。你可以把它理解成给组件状态装了一个统一调度中心——组件内部不再直接修改状态而是通过派发动作dispatch action去触发状态变化真正决定状态怎么变的是那个 reducer 函数。它主要解决几类问题多个关联状态字段需要一起更新。比如表单的多个输入框、分页的页码和每页条数、筛选条件和搜索结果这些状态往往是联动变化的拆成多个 useState 会导致每个 setState 之间互相依赖逻辑分散难以维护。状态更新依赖当前状态的前一个值。典型的计数器、购物车数量加减、撤销重做这类场景如果使用 useState 不小心把 setState 写到异步回调里很容易拿到旧的 state而 useReducer 因为 reducer 是纯函数每次都能拿到最新的状态快照。状态更新有固定的动作类型和流转规则。比如登录状态从未登录到登录中再到已登录/登录失败这类有明确状态机语义的逻辑用 useReducer 表达会清晰得多代码的可读性远超一堆分散的布尔值。需要将状态逻辑复用到多个组件。useReducer 可以和 useContext 搭配实现类似全局状态管理的效果而且不需要引入第三方库。适合谁看呢我觉得有三类人最应该认真学它一是刚学完 React 基础 Hooks、正处在会用 useState 但一写复杂页面就头疼阶段的开发者二是接手过或写过那种状态逻辑乱成一锅粥的组件、想找到更优雅组织方式的人三是在技术方案选型时纠结到底用 Redux 还是 Context useReducer的人。这篇文章不是从 API 文档角度去介绍而是把我实际项目里用 useReducer 的思路、踩过的坑、还有性能分析都摊开来讲尽量让你看完就能直接上手用。2. useReducer 的核心心智模型不是替代 useState而是换一种管理思路2.1 reducer 到底是什么一个做饭的例子很多初学者看到 reducer 这个词就头疼觉得是函数式编程里的高级概念。其实没那么玄乎。你可以把 reducer 想象成一个做饭的师傅组件是顾客它把点菜单action递给师傅reducer 是师傅它根据菜单上写的菜名type决定该炒什么菜新的状态而炒出来的菜新 state端回给顾客。在这个模型里有几个关键点顾客不能自己进厨房翻锅铲。对应到代码里组件永远不要直接给状态赋值只能通过 dispatch 传递想做什么这个意图。师傅只看菜名做菜。reducer 只根据传入的 action 决定返回什么新状态它不关心谁点了菜、为什么点菜也不关心是不是有另一份菜单在同时被处理。同一道菜每次做出来味道一样。这是纯函数pure function的核心要求——给定相同的 state 和 action永远返回相同的结果不做任何副作用不请求接口、不写日志、不操作 DOM。下面上一个最经典的最小例子import { useReducer } from react; function counterReducer(state, action) { switch (action.type) { case increment: return { count: state.count 1 }; case decrement: return { count: state.count - 1 }; case reset: return { count: 0 }; default: return state; } } function Counter() { const [state, dispatch] useReducer(counterReducer, { count: 0 }); return ( div p当前计数{state.count}/p button onClick{() dispatch({ type: increment })}1/button button onClick{() dispatch({ type: decrement })}-1/button button onClick{() dispatch({ type: reset })}重置/button /div ); }这个例子里的counterReducer接收两个参数当前的 state 和 action。action 是一个普通对象约定俗成至少有一个type字段用来告诉 reducer 应该走哪条更新逻辑。reducer 通过switch也可以用 if-else但 switch 的语义更清晰判断 action.type然后返回一个全新的对象作为新状态。2.2 useReducer 的完整签名和每个参数的作用useReducer 的完整签名有三种重载形式// 形式一不传初始值state 为 undefined const [state, dispatch] useReducer(reducer); // 形式二普通初始值 const [state, dispatch] useReducer(reducer, initialArg); // 形式三惰性初始化lazy initialization const [state, dispatch] useReducer(reducer, initialArg, init);我把每个参数的作用和注意点整理成一张表参数作用使用要点reducer纯函数接收 (state, action)返回新 state不要在里面做副作用不要在里面调用 setState 或其他 HookinitialArg初始状态的值如果第三个参数 init 存在这个值会作为 init 的参数传入init可选函数用来惰性初始化适合需要从 props、localStorage、接口缓存等计算初始状态的场景dispatch派发函数用来触发状态更新dispatch 函数本身是稳定的stale closure 问题里最关键的优势这里重点说两个细节。第一个细节是惰性初始化。先看代码function init(initialCount) { // 这里可以做复杂计算比如从 localStorage 读取或者对 props 做转换 return { count: initialCount, timestamp: Date.now() }; } const [state, dispatch] useReducer(reducer, 5, init);当第三个参数 init 存在时useReducer 会把第二个参数 initialArg这里是 5传给 init用init(5)的返回值作为初始 state。为什么叫惰性因为 init 函数只会在组件首次渲染时执行一次之后的重新渲染不会重复调用。如果你的初始状态需要做开销较大的计算比如解析 JSON、遍历数组、读取缓存用这种形式可以避免每一次渲染都白算一遍。相比之下如果直接把计算写在组件体里再传给 useReducer那每次渲染都会执行一次计算。第二个细节是 dispatch 函数的稳定性。useReducer 返回的 dispatch 在组件的整个生命周期里是保持不变的引用不变这意味着如果你把它传给子组件、useMemo 的依赖数组、或者放进 effect 的依赖里都不会因为父组件重新渲染而导致子组件不必要的重渲染或 effect 重新执行。这是 useState 的 setState 同样具备的特性但很多写 useReducer 的人没意识到这点导致依赖数组里多了一个不稳定的函数引用引发各种诡异问题。2.3 和 useState 的对比什么时候选谁我想先打破一个常见的误解useReducer 并不是 useState 的高级版两者是并列的状态管理工具各有适合的场景。useState 适合独立、简单的状态字段比如一个弹窗的开合、一个 loading 开关状态之间没有联动关系更新逻辑简单不需要集中管理状态数量少组件本身不复杂useReducer 适合多个状态字段之间有联动比如筛选条件变化后分页要重置状态更新依赖当前值且有多条明确的更新路径状态有固定的动作类型集合适合类型系统约束希望把状态逻辑抽出来单独测试reducer 是纯函数单测极其方便我举个实际例子。假如你要写一个搜索页面状态包括搜索关键词、当前页码、每页条数、总条数、加载状态、错误信息。这些字段不是独立的——关键词变化时页码要重置为 1每页条数变化时页码也可能要重置加载开始和结束要联动修改 loading 字段。如果全用 useState你会在组件里到处写啊这里还要把 page 重置很容易漏掉某一条联动bug 就出现了。用 useReducer 的话这些联动规则都收拢在 reducer 里function searchReducer(state, action) { switch (action.type) { case SET_KEYWORD: // 关键词一变重置页码 return { ...state, keyword: action.keyword, page: 1 }; case SET_PAGE: return { ...state, page: action.page }; case SET_PAGE_SIZE: return { ...state, pageSize: action.pageSize, page: 1 }; case FETCH_START: return { ...state, loading: true, error: null }; case FETCH_SUCCESS: return { ...state, loading: false, result: action.result, total: action.total }; case FETCH_ERROR: return { ...state, loading: false, error: action.error }; default: return state; } }这样一写所有关键词变化导致页码重置之类的联动逻辑都集中在一个函数里代码审查者只需要看 reducer 就能理解状态流转的完整规则。相比之下useState 的版本会把联动规则散落在事件处理函数里一旦组件膨胀起来查找成本成倍上升。不过也要泼一盆冷水如果你的状态很简单只有一个布尔值、一个数字强行 useReducer 反而显得过度设计代码量多了可读性未必提升。我的建议是当你在 useState 版本里发现自己开始手动同步多个 setState或者为了联动写了很多 if 判断时才是切换到 useReducer 的最佳时机。3. 从零写一个购物车编辑器完整实战拆解理论说再多不如把一个有代表性的项目从头到尾写一遍。我用一个购物车编辑器作为例子它几乎涵盖了 useReducer 实战里最常见的状态类型和联动场景商品列表支持增加、减少数量支持按商品 ID 删除支持清空购物车支持批量设置某个分类下所有商品的数量实时计算总价、总件数支持撤销上一次操作上面的需求如果全用 useState大概要维护一个商品数组、一个总数变量但它又应该由商品数组推导出来、一个撤销栈逻辑散落各处。而 useReducer 可以把这些全部收敛成一个 reducer外加一个独立的撤销栈逻辑。3.1 先定义状态结构和动作类型我习惯先定义状态结构和动作类型再写 reducer。这里直接用 JavaScript 的createReducer配合常量如果项目用 TypeScript更推荐用Discriminated Union联合类型约束每个 action 的 payload这点后面单独展开。// 商品项结构 // { // id: string; // name: string; // price: number; // quantity: number; // category: string; // } const initialState { items: [ { id: p1, name: 机械键盘, price: 399, quantity: 1, category: 外设 }, { id: p2, name: 显示器, price: 1299, quantity: 1, category: 外设 }, { id: p3, name: 电竞椅, price: 899, quantity: 1, category: 家具 }, ], history: [], // 存放过去的状态快照用于撤销 future: [], // 存放撤销后可以重做的快照 };动作类型初步设计如下const ACTIONS { INCREASE_ITEM: INCREASE_ITEM, DECREASE_ITEM: DECREASE_ITEM, REMOVE_ITEM: REMOVE_ITEM, CLEAR_CART: CLEAR_CART, SET_CATEGORY_QUANTITY: SET_CATEGORY_QUANTITY, UNDO: UNDO, REDO: REDO, };3.2 实现 reducer每个 case 背后的状态变更规则下面是我实际写的 reducer 的核心部分。注意几个关键点每次修改 items 的操作都要先更新历史栈items 的更新一律用不可变immutable的方式返回新数组UNDO和REDO从对应的栈里弹出快照。function cartReducer(state, action) { switch (action.type) { case ACTIONS.INCREASE_ITEM: { const nextItems state.items.map(item item.id action.payload.id ? { ...item, quantity: item.quantity 1 } : item ); return pushHistory(state, nextItems); } case ACTIONS.DECREASE_ITEM: { const nextItems state.items.map(item item.id action.payload.id item.quantity 1 ? { ...item, quantity: item.quantity - 1 } : item ); return pushHistory(state, nextItems); } case ACTIONS.REMOVE_ITEM: { const nextItems state.items.filter(item item.id ! action.payload.id); return pushHistory(state, nextItems); } case ACTIONS.CLEAR_CART: { const nextItems []; return pushHistory(state, nextItems); } case ACTIONS.SET_CATEGORY_QUANTITY: { const { category, quantity } action.payload; const nextItems state.items.map(item item.category category ? { ...item, quantity } : item ); return pushHistory(state, nextItems); } case ACTIONS.UNDO: { if (state.history.length 0) return state; const previous state.history[state.history.length - 1]; return { ...state, items: previous, history: state.history.slice(0, -1), future: [state.items, ...state.future], }; } case ACTIONS.REDO: { if (state.future.length 0) return state; const next state.future[0]; return { ...state, items: next, history: [...state.history, state.items], future: state.future.slice(1), }; } default: return state; } } function pushHistory(state, nextItems) { return { ...state, items: nextItems, history: [...state.history, state.items], future: [], // 一旦产生新操作清空重做栈 }; }这里有几个我在实践中反复强调的细节永远不要直接修改 state.items。map、filter返回新数组但注意 map 内部如果只改某个 item 的 quantity也要用{ ...item, quantity: ... }新建对象否则该 item 的旧引用会进入 history 栈撤销时可能出现改了但没完全改的诡异表现。history 栈存的是快照引用不深拷贝。因为每次修改都产生新的 items 数组和新的 item 对象旧的引用天然不可变存引用既可节省内存又保证不可变性不被破坏。前提是你在所有 case 里都严格贯彻不可变更新。UNDO/REDO 要注意栈的边界条件。栈为空时直接返回原 state避免 undefined 项混入。3.3 组件层的事件组织dispatch 如何传递意图reducer 写完之后组件层其实非常薄。每个用户操作只是组织一个 action 对象 dispatch 出去不直接触碰状态的计算。这是我写的组件部分function CartEditor() { const [state, dispatch] useReducer(cartReducer, initialState); const totalCount state.items.reduce((sum, item) sum item.quantity, 0); const totalPrice state.items.reduce( (sum, item) sum item.price * item.quantity, 0 ); return ( div div classNametoolbar button onClick{() dispatch({ type: ACTIONS.UNDO })} disabled{state.history.length 0} 撤销 /button button onClick{() dispatch({ type: ACTIONS.REDO })} disabled{state.future.length 0} 重做 /button button onClick{() dispatch({ type: ACTIONS.CLEAR_CART })}清空购物车/button /div ul {state.items.map(item ( li key{item.id} span{item.name}/span span单价{item.price}/span button onClick{() dispatch({ type: ACTIONS.DECREASE_ITEM, payload: { id: item.id } })} - /button span{item.quantity}/span button onClick{() dispatch({ type: ACTIONS.INCREASE_ITEM, payload: { id: item.id } })} /button button onClick{() dispatch({ type: ACTIONS.REMOVE_ITEM, payload: { id: item.id } })} 删除 /button /li ))} /ul p总件数{totalCount}/p p总价{totalPrice}/p /div ); }这个例子里组件唯一的计算是把总件数和总价通过reduce推导出来。注意我这里用的是派生状态derived state而不是直接在 reducer 里维护 total 字段——这是刻意为之。总价、总件数完全可以由 items 数组推导出来如果每次操作都去重新计算 total 并写进 state不仅增加状态字段的一致性维护成本可能会出现 items 变了 total 没变的 bug还会让每个 reducer case 都要记得更新 total非常容易遗漏。能从现有 state 推导出来的数据就不要存进 state这是 React 状态设计的一条铁律。3.4 这个例子的可扩展方向购物车编辑器只是一个小例子但它背后的模式可以扩展出很多实际功能把 reducer 从组件文件里单独抽出去放到reducers/cartReducer.js配合单测覆盖每个 action非常爽。我在项目里就用 vitest 对 reducer 写过几十个用例每个 case 一两个 it把各种边界条件空车、数量为 1 再减、重复撤销到底全部钉死。把 items 初始化改为从接口加载加载完成后 dispatch 一个SET_ITEMSaction就实现了数据回填 历史干净的效果。如果商品支持优惠券优惠券逻辑是叠加计算还是互斥计算天然适合放在 reducer 里处理因为它的动作类型是明确的一小撮。4. useReducer 在异步场景下的使用实践从在 reducer 里请求到请求放在哪异步处理是 useReducer 实践里最容易让人纠结的地方。Redux 社区早就验证过reducer 必须是纯函数不能在里面请求接口。但 useReducer 没有官方配套的中间件很多人复制 Redux 的习惯放一个 thunk 又觉得重不放又不知道怎么处理 loading、success、error 三个状态。我先给结论在组件或自定义 Hook 里发起异步请求然后 dispatch 不同的 action 通知 reducer 当前处于什么阶段loading / success / error这是最通用、最贴合 useReducer 心智的方案。4.1 一个典型的异步请求流程怎么写以用户登录为例。状态字段包括statusidle / loading / success / error、userInfo、errorMessage。用 useReducer 管理function authReducer(state, action) { switch (action.type) { case LOGIN_START: return { ...state, status: loading, error: null }; case LOGIN_SUCCESS: return { ...state, status: success, user: action.payload }; case LOGIN_FAILURE: return { ...state, status: error, error: action.payload }; case LOGOUT: return { ...state, status: idle, user: null }; default: return state; } }组件内部的登录函数async function handleLogin(username, password) { dispatch({ type: LOGIN_START }); try { const user await loginApi(username, password); dispatch({ type: LOGIN_SUCCESS, payload: user }); } catch (err) { dispatch({ type: LOGIN_FAILURE, payload: err.message }); } }这个写法的好处一眼就能看出来loading、success、error 三个状态被完整建模了不会出现请求进行中用户又点了一次登录时 loading 状态错乱的问题组件层看起来就是一个瞬时的 dispatch没有任何中间状态需要手动 sync。缺点也明显每次写一个接口调用都要手动写三个 dispatch模板代码有点多。但我更倾向于显式比隐式好——可读性和可调试性胜过一点模板代码。4.2 要不要自己封装一个简单的 async action helper如果你的项目里大量使用 useReducer 处理异步可以封装一个非常轻量的辅助函数不用引入第三方库function createAsyncDispatcher(type, promiseCreator) { return async function (dispatch, payload) { dispatch({ type: ${type}_START, payload }); try { const result await promiseCreator(payload); dispatch({ type: ${type}_SUCCESS, payload: result }); return result; } catch (err) { dispatch({ type: ${type}_FAILURE, payload: err.message }); throw err; } }; } // 使用示例 const fetchUserDispatcher createAsyncDispatcher(FETCH_USER, fetchUserApi); async function loadUser(userId) { try { await fetchUserDispatcher(dispatch, { userId }); } catch (e) { // 已经由 FAILURE action 处理状态这里可以忽略或做额外处理 } }这种模式本质上是手动实现了一个简化版的 thunk。我测试下来在中小型项目里完全够用而且比引入 Redux Toolkit 轻得多。不过要提醒一点不要把异步逻辑放进 reducer 里。比如在 reducer 的LOGIN_STARTcase 里去调用loginApi然后等结果回来再 dispatch 另外一个 action——这种写法破坏了 reducer 的纯函数特性会导致难以追踪的状态变更、重复执行、以及 React StrictMode 下 double-invoke 引发的隐患StrictMode 在开发环境会故意多次调用 reducer 来检查纯函数性如果你在里面发请求会被调用两次逻辑直接炸掉。4.3 竞态条件一个容易被忽略的坑异步操作还有一个常见问题是竞态条件race condition即用户快速触发多次请求后发出的请求先返回导致最终展示的数据是旧请求的结果。useReducer 本身不解决这个问题需要你在 dispatch 之前做校验或者在 effect 里用 AbortController 取消过期请求。我处理过的实际场景是搜索框用户输入React又快速改成Reducer网络慢的话第一次请求可能比第二次后返回。如果直接 dispatchSEARCH_SUCCESS界面就会显示Reducer的关键词却对应React的搜索结果搜索词和结果对不上用户会觉得很奇怪。解决方案是在 effect 里做一个简单的过期标记useEffect(() { let ignore false; async function fetchResults() { dispatch({ type: SEARCH_START }); const results await searchApi(keyword); if (!ignore) { dispatch({ type: SEARCH_SUCCESS, payload: results }); } } fetchResults(); return () { ignore true; }; }, [keyword]);cleanup 函数把ignore置为 true意味着组件卸载或 keyword 再次变化时旧请求即使返回了也不会再 dispatch 任何 action。这个模式配合 useReducer 的状态管理非常顺滑——reducer 只管状态怎么变而这个请求还该不该更新状态由调用方控制职责清晰。5. useReducer useContext打造一个不需要第三方库的轻量全局状态方案我经常被问到项目状态共享到底选 Redux 还是 Zustand 还是 Context useReducer。我的回答是如果你的需求主要是多组件共享某个领域状态、状态变更逻辑有明确规则、不想为一个小模块引入大而全的全局状态库那 useReducer useContext 完全能胜任。5.1 组合的完整代码模式以一个用户偏好设置为例涉及到主题模式、字体大小、语言三项设置多个组件设置面板、文章页、导航栏都要读取和修改。先定义 Context 和 Providerimport { createContext, useContext, useReducer } from react; const SettingsContext createContext(null); function settingsReducer(state, action) { switch (action.type) { case SET_THEME: return { ...state, theme: action.payload }; case SET_FONT_SIZE: return { ...state, fontSize: action.payload }; case SET_LANGUAGE: return { ...state, language: action.payload }; case RESET: return { ...state, theme: light, fontSize: 14, language: zh-CN }; default: return state; } } const initialState { theme: light, fontSize: 14, language: zh-CN }; export function SettingsProvider({ children }) { const [state, dispatch] useReducer(settingsReducer, initialState); return ( SettingsContext.Provider value{{ state, dispatch }} {children} /SettingsContext.Provider ); }组件内部读取和更新function SettingsPanel() { const { state, dispatch } useContext(SettingsContext); return ( div select value{state.theme} onChange{(e) dispatch({ type: SET_THEME, payload: e.target.value })} option valuelight浅色/option option valuedark深色/option /select input typerange min12 max24 value{state.fontSize} onChange{(e) dispatch({ type: SET_FONT_SIZE, payload: Number(e.target.value) })} / button onClick{() dispatch({ type: RESET })}恢复默认/button /div ); }所有需要共享设置的组件都可以通过useContext(SettingsContext)拿到统一的 state 和 dispatch。状态变更完全由 reducer 控制不会出现在 A 组件改了 localStorage 但 B 组件不知道的同步问题。5.2 性能注意事项不瞎优化但也不用摆烂Context useReducer 的性能一直是讨论热点。每次 state 更新Provider 的 value 是一个新对象所有消费了这个 Context 的组件都会重新渲染。这是 Context 的固有行为不是 useReducer 的锅。性能优化的几个实用建议按领域拆分 Context。不要把所有全局状态塞进一个巨型 Context。比如把用户信息和主题设置拆成两个 Provider主题切换时用户信息相关的组件不会受影响。把 Context value 用 useMemo 包裹。这样只有当 state 真正变化时才生成新的 value 对象。const value useMemo(() ({ state, dispatch }), [state, dispatch]);因为 dispatch 本身稳定这个 useMemo 实际等价于[state]能减少一部分无意义的子组件重渲染。用 selector 模式裁剪 Consumer。如果只有一个组件需要状态里的theme字段而另一个组件只需要fontSize可以自己写一个小的 useSelector 样式封装。不过对于中小型项目我建议先别过度设计等真的出现性能瓶颈或者能明显感知页面卡顿再拆。dispatch 函数的稳定性是最大加分项。因为 dispatch 在整个生命周期不变子组件即使每次都重新渲染也只有在事件触发时才会拿到新的 action 对象依赖 dispatch 的 useMemo、useEffect 都不会被频繁重建这点比直接在 Context 里传一堆回调函数要克制得多。5.3 什么时候该升级到 Redux 或 Zustand我自己会遵守几个判断标准状态是全局性的、跨多个页面、更新频率高比如用户实时位置、在线状态、播放列表需要 DevTools 时间旅行调试、持久化中间件、请求缓存等 Redux 生态能力团队成员对 Redux 的模式更熟悉维护成本反而更低状态逻辑足够复杂需要引入实体关系、规范化存储normalized state等概念如果只是上面购物车、设置的规模useReducer Context 完全绰绰有余。引入一个全局状态库的成本不只是包体积还有团队关于什么时候该 dispatch、什么时候该用 selector、action 怎么命名的规约成本。能用原生 Hooks 解决的先用原生 Hooks 解决这是我在实际项目中反复验证过的稳妥路线。6. 我在生产环境里踩过的坑与排查方法useReducer 用起来比 useState 稍微复杂坑也更多。这一节我把生产环境里真正踩过的几个坑整理成完整的排查链路分享我当时的排查过程和最终修复方案希望你能直接避雷。6.1 坑一reducer 里不小心做了副作用导致 StrictMode 下状态多算一次现象开发环境下counter 每次点击 1数字却变成 2。用户一脸懵我也一脸懵。排查过程我先检查是不是 onClick 绑定出了问题后来注释掉 StrictMode 发现数字恢复正常。这时我意识到 React 在开发环境的 StrictMode 下会故意调用两次 reducer和两次 render目的就是把 impure reducer 的问题提前暴露出来。我把counterReducer打开一看里面竟然写了一个console.log和localStorage.setItem——这俩都是副作用在 StrictMode 下被执行两次导致一些外部状态被重复写入表现就是数字变化异常。修复方案把副作用从 reducer 里全部挪走。持久化操作用 useEffect 监听 state 变化统一处理日志也移到组件层。reducer 只保留纯粹的state 转换逻辑。这个坑我印象极深因为它不是 error而是看起来正常但结果不对的类型非常难定位。排查到的核心思路是只要发现开发环境行为和生产环境不一致优先怀疑 StrictMode 和 impure reducer 的组合。6.2 坑二初始化函数 init 里用了组件的 props但 props 更新后状态却没有跟着变现象某个筛选组件父组件传入defaultFilterprops子组件第一次渲染时用它初始化 state。父组件更新 props 后子组件状态没有重置筛选条件停留在旧值。排查过程一开始我以为 useReducer 的 initialArg 变化会自动触发重新初始化查了文档才知道initialArg只在首次渲染时用一次后续 props 变化并不会重置 reducer 状态。很多人会把 reducer 当成响应式的state computeFromProps模型其实它是一次性初始化 事件驱动更新的模型。修复方案要看产品预期是什么——如果 props 变化时确实想重置状态需要在组件里手动处理useEffect(() { dispatch({ type: RESET_FROM_PROPS, payload: { defaultFilter: defaultFilterProp } }); }, [defaultFilterProp]);或者直接用key{newKey}强制整个组件重新挂载但成本较高。我当时选择了第一种并且把RESET_FROM_PROPS定义成 reducer 里的一个显式 action逻辑清晰以后也好测试。6.3 坑三dispatch 传入的 action 对象被误当成可变对象多次修改导致 reducer 内部出现怪异分支现象我写过一个批量操作功能事件处理里先buildAction()构造一个 action然后在某个循环里给这个 action 添加额外字段最后 dispatch 出去。结果 reducer 里对同一 action 走到了完全错误的 case排查了一整个下午。排查过程后来发现我在循环里action.payload.count ...这种写法导致同一个 action 对象在 reducer 内部被重复读取时 payload 已经变了switch 判断的 type 没有变但分支里的计算全部基于被改过的 payload结果自然不对。修复方案action 对象也应当被视为不可变对象。要修改就新建对象不要复用。我后来把所有构造 action 的逻辑统一改成显式返回新对象dispatch({ type: ACTIONS.BATCH_SET, payload: { ids, quantity: newQuantity }, });并且给自己立了个规矩dispatch 出去的 action不要再碰它也不要试图在事件处理函数里 mutate 它。这条规矩让异步回调里的 action 构造也安全了很多。6.4 坑四错误地把派生状态存进 reducer导致状态不一致现象购物车例子中我一开始把totalPrice作为一个独立字段存在 state 里每次增减商品时都手动计算并更新。后来新增了批量设置数量的 action忘记更新 totalPrice页面上总数对不上。用户反馈明明 5 件商品但总价显示的是 4 件的钱。排查过程追踪 state 发现items正确totalPrice是旧值。这个 bug 的本质是冗余状态derived state 被重复存储破坏了单一数据源原则。因为如果每个 action 都要记得更新 totalPrice迟早有遗漏。修复方案把 totalPrice 从 state 中移除在组件层用useMemo或直接reduce计算const totalPrice useMemo( () state.items.reduce((sum, item) sum item.price * item.quantity, 0), [state.items] );这不仅是重构更是一个值得记住的设计原则能让 React 自动推导的状态就不要让 reducer 手动维护。6.5 坑五撤销功能里用了push而不是concat导致历史栈状态被污染现象实现撤销时我用history.push(state.items)把当前 items 推入历史栈。第一次撤销正常第二次撤销时发现回到了一个中间态而不是最初态。排查过程问题出在push会原地修改数组而这个数组正是当前 state.items 的引用。当我在后续操作中基于同一数组修改时历史栈里存的引用也被改了历史变成了可变历史。修复方案一律用不可变操作history: [...state.history, state.items]这个坑特别隐蔽因为 JavaScript 数组的push返回新长度而不是新数组很容易让人忽略它修改的是原数组。凡是和不可变数据打交道的地方都要养成用concat/展开运算符 的习惯。6.6 排查思路小结我在踩了这些坑之后总结了一套流程分享给你作为参考先看 StrictMode 下是否复现复现则优先怀疑 reducer 不纯再确认 action 载荷是否在 dispatch 前后被意外改动看一下是否有字段违反单一数据源原则翻一下是否有类似push的原地修改操作最后检查初始化逻辑里是否依赖了后续 props 的变化这套顺序基本覆盖了 useReducer 90% 的常见问题建议你遇到异常的时候照着走一遍比打印一堆日志来得快。7. useReducer 面向 TypeScript 的实战姿势用 Discriminated Union 约束所有裸奔的 action如果你的项目用了 TypeScriptuseReducer 会变得更香——因为 error 可以从运行时才发现提前到编译时就被拦截。这是我目前最推荐的一节也是很多人没用好 useReducer 的原因。7.1 一个标准的 Discriminated Union action 写法关键思想把所有可能的 action 类型定义为一个联合类型每种 action 通过type字面量区分同时用 TypeScript 收窄narrowing让每个 case 里都能正确推断 payload 的类型。type UserState { user: { id: string; name: string } | null; status: idle | loading | success | error; error: string | null; }; type UserAction | { type: FETCH_USER_START } | { type: FETCH_USER_SUCCESS; payload: { id: string; name: string } } | { type: FETCH_USER_FAILURE; payload: string } | { type: LOGOUT }; function userReducer(state: UserState, action: UserAction): UserState { switch (action.type) { case FETCH_USER_START: return { ...state, status: loading, error: null }; case FETCH_USER_SUCCESS: return { ...state, status: success, user: action.payload }; case FETCH_USER_FAILURE: return { ...state, status: error, error: action.payload }; case LOGOUT: return { ...state, user: null, status: idle }; default: // 这里推荐用 exhaustive check确保所有分支都被覆盖 return state; } }注意这行代码return state前面的 default。TS 里如果你把所有 action 分支都写完了default 分支实际上是不可达的。你可以用exhaustive技巧让它编译报错function assertNever(x: never): never { throw new Error(Unexpected object: x); } function userReducer(state: UserState, action: UserAction): UserState { switch (action.type) { ... default: return assertNever(action); } }这样如果有人给UserAction加了新类型但忘了写 caseTS 会直接报错而不是等运行时才出问题。这是我强烈推荐的一个小技巧能帮团队省下大量漏写分支的 debug 时间。7.2 把 reducer 单独抽出来做单元测试的体验reducer 因为是纯函数测试体验可以说是 React 状态管理方案里最好的之一。我用 vitest 写过下面这样的测试import { describe, it, expect } from vitest; import { userReducer, initialState } from ./userReducer; describe(userReducer, () { it(should handle FETCH_USER_SUCCESS, () { const state userReducer(initialState, { type: FETCH_USER_SUCCESS, payload: { id: 1, name: 张三 }, }); expect(state.status).toBe(success); expect(state.user).toEqual({ id: 1, name: 张三 }); }); it(should handle FETCH_USER_FAILURE, () { const state userReducer(initialState, { type: FETCH_USER_FAILURE, payload: 网络错误, }); expect(state.status).toBe(error); expect(state.error).toBe(网络错误); }); });写这类测试几乎没有成本因为不需要 mock 任何 DOM、HTTP 或组件。回购车、撤销、重置这些业务规则时我都是先把 reducer 的测试写好再写组件测试先行让重构安全感大大提高。很多前端项目不写测试不是不想写而是组件测试成本太高useReducer 恰好把逻辑和视图切得很干净是测试性价比最高的抓手。7.3 reducer 文件结构怎么组织才不乱实际项目里当 action 类型变多我习惯把 reducer 拆成这样features/ cart/ reducer.ts actions.ts types.ts useCart.ts CartEditor.tsx其中types.ts放CartState、CartAction等类型定义actions.ts放 action creator 函数目的是提供类型安全且方便调用的 dispatch 参数reducer.ts放纯函数 initialStateuseCart.ts是一个自定义 Hook将 useReducer、派生状态和事件方法都包装起来组件层只消费useCart()自定义 Hook 的长相大概是function useCart() { const [state, dispatch] useReducer(cartReducer, undefined, createInitialCart); const totalPrice useMemo( () state.items.reduce((sum, item) sum item.price * item.quantity, 0), [state.items] ); const addItem useCallback((item: CartItem) { dispatch({ type: ADD_ITEM, payload: item }); }, []); const removeItem useCallback((id: string) { dispatch({ type: REMOVE_ITEM, payload: { id } }); }, []); return { state, totalPrice, addItem, removeItem, dispatch }; }这样组件里就不再出现dispatch({ type: ACTIONS.REMOVE_ITEM, payload: { id }})这种细碎代码而是调removeItem(id)语义更清晰也方便在 Hook 层统一处理派生状态。这个模式我愿称之为 useReducer 的终极形态reducer 管状态规则、useMemo 管派生状态、useCallback 管事件方法、组件只管渲染。8. 写在最后useReducer 的真实定位与我的使用建议我在不同规模的项目里试过各种状态方案最后给 useReducer 的定位是它是 React 原生状态管理里规则化与轻量之间的最佳平衡点。它比 useState 多了一层action 语义让状态变化有了名字和规则代码可读性和可维护性明显提升它比 Redux 少了中间件生态和全局单例正因为轻所以反而更容易被理解和被掌控。它不是万能的复杂到一定程度该上 Redux/Zustand 还是要上但作为日常开发的主力状态方案它非常靠谱。如果你现在正处在要不要从 useState 换成 useReducer的纠结里我给个简单的判断方法打开你的组件文件数一下setState的数量和它们之间的联动关系。超过三个且联动明显或者你发现自己在事件处理函数里写了既要改 A 又要重置 B 还要清空 C那今天就动手试试 useReducer 吧。别担心多出来的模板代码——几乎所有从 useState 切到 useReducer 的人清理完几个组件后都会有种以前怎么没想到的畅快感。最后再分享一个小技巧如果你想让 useReducer 的调试体验更顺滑可以在 dispatch 外面包一层日志函数把 action 打出来配合 React DevTools 的 reducer 状态追踪线上出 bug 时定位效率会快很多。当然这层日志只用放在开发环境生产环境记得去掉。用 useReducer 最大的快乐从来不是代码少了几行而是当状态逻辑越来越庞杂时你依然能一眼看穿它每一步是怎么走到这里的。
1. 从useState到useReducer为什么你需要第二个状态方案这两年我在跟不少前端开发者交流时发现一个很有意思的现象很多人写 React 组件一遇到复杂状态就下意识地堆 useState结果状态逻辑越写越乱组件层级越来越深到最后连自己都理不清状态是怎么变化的。我在实际项目里也踩过这个坑后来认真把 useReducer 吃透之后再看那些状态复杂的需求思路完全不一样了。先说不绕弯子的结论useReducer 是 React 提供的一个用于管理复杂状态逻辑的 Hook它的核心思想是把状态的更新规则从组件里抽离出来集中到一个纯函数里统一管理。你可以把它理解成给组件状态装了一个统一调度中心——组件内部不再直接修改状态而是通过派发动作dispatch action去触发状态变化真正决定状态怎么变的是那个 reducer 函数。它主要解决几类问题多个关联状态字段需要一起更新。比如表单的多个输入框、分页的页码和每页条数、筛选条件和搜索结果这些状态往往是联动变化的拆成多个 useState 会导致每个 setState 之间互相依赖逻辑分散难以维护。状态更新依赖当前状态的前一个值。典型的计数器、购物车数量加减、撤销重做这类场景如果使用 useState 不小心把 setState 写到异步回调里很容易拿到旧的 state而 useReducer 因为 reducer 是纯函数每次都能拿到最新的状态快照。状态更新有固定的动作类型和流转规则。比如登录状态从未登录到登录中再到已登录/登录失败这类有明确状态机语义的逻辑用 useReducer 表达会清晰得多代码的可读性远超一堆分散的布尔值。需要将状态逻辑复用到多个组件。useReducer 可以和 useContext 搭配实现类似全局状态管理的效果而且不需要引入第三方库。适合谁看呢我觉得有三类人最应该认真学它一是刚学完 React 基础 Hooks、正处在会用 useState 但一写复杂页面就头疼阶段的开发者二是接手过或写过那种状态逻辑乱成一锅粥的组件、想找到更优雅组织方式的人三是在技术方案选型时纠结到底用 Redux 还是 Context useReducer的人。这篇文章不是从 API 文档角度去介绍而是把我实际项目里用 useReducer 的思路、踩过的坑、还有性能分析都摊开来讲尽量让你看完就能直接上手用。2. useReducer 的核心心智模型不是替代 useState而是换一种管理思路2.1 reducer 到底是什么一个做饭的例子很多初学者看到 reducer 这个词就头疼觉得是函数式编程里的高级概念。其实没那么玄乎。你可以把 reducer 想象成一个做饭的师傅组件是顾客它把点菜单action递给师傅reducer 是师傅它根据菜单上写的菜名type决定该炒什么菜新的状态而炒出来的菜新 state端回给顾客。在这个模型里有几个关键点顾客不能自己进厨房翻锅铲。对应到代码里组件永远不要直接给状态赋值只能通过 dispatch 传递想做什么这个意图。师傅只看菜名做菜。reducer 只根据传入的 action 决定返回什么新状态它不关心谁点了菜、为什么点菜也不关心是不是有另一份菜单在同时被处理。同一道菜每次做出来味道一样。这是纯函数pure function的核心要求——给定相同的 state 和 action永远返回相同的结果不做任何副作用不请求接口、不写日志、不操作 DOM。下面上一个最经典的最小例子import { useReducer } from react; function counterReducer(state, action) { switch (action.type) { case increment: return { count: state.count 1 }; case decrement: return { count: state.count - 1 }; case reset: return { count: 0 }; default: return state; } } function Counter() { const [state, dispatch] useReducer(counterReducer, { count: 0 }); return ( div p当前计数{state.count}/p button onClick{() dispatch({ type: increment })}1/button button onClick{() dispatch({ type: decrement })}-1/button button onClick{() dispatch({ type: reset })}重置/button /div ); }这个例子里的counterReducer接收两个参数当前的 state 和 action。action 是一个普通对象约定俗成至少有一个type字段用来告诉 reducer 应该走哪条更新逻辑。reducer 通过switch也可以用 if-else但 switch 的语义更清晰判断 action.type然后返回一个全新的对象作为新状态。2.2 useReducer 的完整签名和每个参数的作用useReducer 的完整签名有三种重载形式// 形式一不传初始值state 为 undefined const [state, dispatch] useReducer(reducer); // 形式二普通初始值 const [state, dispatch] useReducer(reducer, initialArg); // 形式三惰性初始化lazy initialization const [state, dispatch] useReducer(reducer, initialArg, init);我把每个参数的作用和注意点整理成一张表参数作用使用要点reducer纯函数接收 (state, action)返回新 state不要在里面做副作用不要在里面调用 setState 或其他 HookinitialArg初始状态的值如果第三个参数 init 存在这个值会作为 init 的参数传入init可选函数用来惰性初始化适合需要从 props、localStorage、接口缓存等计算初始状态的场景dispatch派发函数用来触发状态更新dispatch 函数本身是稳定的stale closure 问题里最关键的优势这里重点说两个细节。第一个细节是惰性初始化。先看代码function init(initialCount) { // 这里可以做复杂计算比如从 localStorage 读取或者对 props 做转换 return { count: initialCount, timestamp: Date.now() }; } const [state, dispatch] useReducer(reducer, 5, init);当第三个参数 init 存在时useReducer 会把第二个参数 initialArg这里是 5传给 init用init(5)的返回值作为初始 state。为什么叫惰性因为 init 函数只会在组件首次渲染时执行一次之后的重新渲染不会重复调用。如果你的初始状态需要做开销较大的计算比如解析 JSON、遍历数组、读取缓存用这种形式可以避免每一次渲染都白算一遍。相比之下如果直接把计算写在组件体里再传给 useReducer那每次渲染都会执行一次计算。第二个细节是 dispatch 函数的稳定性。useReducer 返回的 dispatch 在组件的整个生命周期里是保持不变的引用不变这意味着如果你把它传给子组件、useMemo 的依赖数组、或者放进 effect 的依赖里都不会因为父组件重新渲染而导致子组件不必要的重渲染或 effect 重新执行。这是 useState 的 setState 同样具备的特性但很多写 useReducer 的人没意识到这点导致依赖数组里多了一个不稳定的函数引用引发各种诡异问题。2.3 和 useState 的对比什么时候选谁我想先打破一个常见的误解useReducer 并不是 useState 的高级版两者是并列的状态管理工具各有适合的场景。useState 适合独立、简单的状态字段比如一个弹窗的开合、一个 loading 开关状态之间没有联动关系更新逻辑简单不需要集中管理状态数量少组件本身不复杂useReducer 适合多个状态字段之间有联动比如筛选条件变化后分页要重置状态更新依赖当前值且有多条明确的更新路径状态有固定的动作类型集合适合类型系统约束希望把状态逻辑抽出来单独测试reducer 是纯函数单测极其方便我举个实际例子。假如你要写一个搜索页面状态包括搜索关键词、当前页码、每页条数、总条数、加载状态、错误信息。这些字段不是独立的——关键词变化时页码要重置为 1每页条数变化时页码也可能要重置加载开始和结束要联动修改 loading 字段。如果全用 useState你会在组件里到处写啊这里还要把 page 重置很容易漏掉某一条联动bug 就出现了。用 useReducer 的话这些联动规则都收拢在 reducer 里function searchReducer(state, action) { switch (action.type) { case SET_KEYWORD: // 关键词一变重置页码 return { ...state, keyword: action.keyword, page: 1 }; case SET_PAGE: return { ...state, page: action.page }; case SET_PAGE_SIZE: return { ...state, pageSize: action.pageSize, page: 1 }; case FETCH_START: return { ...state, loading: true, error: null }; case FETCH_SUCCESS: return { ...state, loading: false, result: action.result, total: action.total }; case FETCH_ERROR: return { ...state, loading: false, error: action.error }; default: return state; } }这样一写所有关键词变化导致页码重置之类的联动逻辑都集中在一个函数里代码审查者只需要看 reducer 就能理解状态流转的完整规则。相比之下useState 的版本会把联动规则散落在事件处理函数里一旦组件膨胀起来查找成本成倍上升。不过也要泼一盆冷水如果你的状态很简单只有一个布尔值、一个数字强行 useReducer 反而显得过度设计代码量多了可读性未必提升。我的建议是当你在 useState 版本里发现自己开始手动同步多个 setState或者为了联动写了很多 if 判断时才是切换到 useReducer 的最佳时机。3. 从零写一个购物车编辑器完整实战拆解理论说再多不如把一个有代表性的项目从头到尾写一遍。我用一个购物车编辑器作为例子它几乎涵盖了 useReducer 实战里最常见的状态类型和联动场景商品列表支持增加、减少数量支持按商品 ID 删除支持清空购物车支持批量设置某个分类下所有商品的数量实时计算总价、总件数支持撤销上一次操作上面的需求如果全用 useState大概要维护一个商品数组、一个总数变量但它又应该由商品数组推导出来、一个撤销栈逻辑散落各处。而 useReducer 可以把这些全部收敛成一个 reducer外加一个独立的撤销栈逻辑。3.1 先定义状态结构和动作类型我习惯先定义状态结构和动作类型再写 reducer。这里直接用 JavaScript 的createReducer配合常量如果项目用 TypeScript更推荐用Discriminated Union联合类型约束每个 action 的 payload这点后面单独展开。// 商品项结构 // { // id: string; // name: string; // price: number; // quantity: number; // category: string; // } const initialState { items: [ { id: p1, name: 机械键盘, price: 399, quantity: 1, category: 外设 }, { id: p2, name: 显示器, price: 1299, quantity: 1, category: 外设 }, { id: p3, name: 电竞椅, price: 899, quantity: 1, category: 家具 }, ], history: [], // 存放过去的状态快照用于撤销 future: [], // 存放撤销后可以重做的快照 };动作类型初步设计如下const ACTIONS { INCREASE_ITEM: INCREASE_ITEM, DECREASE_ITEM: DECREASE_ITEM, REMOVE_ITEM: REMOVE_ITEM, CLEAR_CART: CLEAR_CART, SET_CATEGORY_QUANTITY: SET_CATEGORY_QUANTITY, UNDO: UNDO, REDO: REDO, };3.2 实现 reducer每个 case 背后的状态变更规则下面是我实际写的 reducer 的核心部分。注意几个关键点每次修改 items 的操作都要先更新历史栈items 的更新一律用不可变immutable的方式返回新数组UNDO和REDO从对应的栈里弹出快照。function cartReducer(state, action) { switch (action.type) { case ACTIONS.INCREASE_ITEM: { const nextItems state.items.map(item item.id action.payload.id ? { ...item, quantity: item.quantity 1 } : item ); return pushHistory(state, nextItems); } case ACTIONS.DECREASE_ITEM: { const nextItems state.items.map(item item.id action.payload.id item.quantity 1 ? { ...item, quantity: item.quantity - 1 } : item ); return pushHistory(state, nextItems); } case ACTIONS.REMOVE_ITEM: { const nextItems state.items.filter(item item.id ! action.payload.id); return pushHistory(state, nextItems); } case ACTIONS.CLEAR_CART: { const nextItems []; return pushHistory(state, nextItems); } case ACTIONS.SET_CATEGORY_QUANTITY: { const { category, quantity } action.payload; const nextItems state.items.map(item item.category category ? { ...item, quantity } : item ); return pushHistory(state, nextItems); } case ACTIONS.UNDO: { if (state.history.length 0) return state; const previous state.history[state.history.length - 1]; return { ...state, items: previous, history: state.history.slice(0, -1), future: [state.items, ...state.future], }; } case ACTIONS.REDO: { if (state.future.length 0) return state; const next state.future[0]; return { ...state, items: next, history: [...state.history, state.items], future: state.future.slice(1), }; } default: return state; } } function pushHistory(state, nextItems) { return { ...state, items: nextItems, history: [...state.history, state.items], future: [], // 一旦产生新操作清空重做栈 }; }这里有几个我在实践中反复强调的细节永远不要直接修改 state.items。map、filter返回新数组但注意 map 内部如果只改某个 item 的 quantity也要用{ ...item, quantity: ... }新建对象否则该 item 的旧引用会进入 history 栈撤销时可能出现改了但没完全改的诡异表现。history 栈存的是快照引用不深拷贝。因为每次修改都产生新的 items 数组和新的 item 对象旧的引用天然不可变存引用既可节省内存又保证不可变性不被破坏。前提是你在所有 case 里都严格贯彻不可变更新。UNDO/REDO 要注意栈的边界条件。栈为空时直接返回原 state避免 undefined 项混入。3.3 组件层的事件组织dispatch 如何传递意图reducer 写完之后组件层其实非常薄。每个用户操作只是组织一个 action 对象 dispatch 出去不直接触碰状态的计算。这是我写的组件部分function CartEditor() { const [state, dispatch] useReducer(cartReducer, initialState); const totalCount state.items.reduce((sum, item) sum item.quantity, 0); const totalPrice state.items.reduce( (sum, item) sum item.price * item.quantity, 0 ); return ( div div classNametoolbar button onClick{() dispatch({ type: ACTIONS.UNDO })} disabled{state.history.length 0} 撤销 /button button onClick{() dispatch({ type: ACTIONS.REDO })} disabled{state.future.length 0} 重做 /button button onClick{() dispatch({ type: ACTIONS.CLEAR_CART })}清空购物车/button /div ul {state.items.map(item ( li key{item.id} span{item.name}/span span单价{item.price}/span button onClick{() dispatch({ type: ACTIONS.DECREASE_ITEM, payload: { id: item.id } })} - /button span{item.quantity}/span button onClick{() dispatch({ type: ACTIONS.INCREASE_ITEM, payload: { id: item.id } })} /button button onClick{() dispatch({ type: ACTIONS.REMOVE_ITEM, payload: { id: item.id } })} 删除 /button /li ))} /ul p总件数{totalCount}/p p总价{totalPrice}/p /div ); }这个例子里组件唯一的计算是把总件数和总价通过reduce推导出来。注意我这里用的是派生状态derived state而不是直接在 reducer 里维护 total 字段——这是刻意为之。总价、总件数完全可以由 items 数组推导出来如果每次操作都去重新计算 total 并写进 state不仅增加状态字段的一致性维护成本可能会出现 items 变了 total 没变的 bug还会让每个 reducer case 都要记得更新 total非常容易遗漏。能从现有 state 推导出来的数据就不要存进 state这是 React 状态设计的一条铁律。3.4 这个例子的可扩展方向购物车编辑器只是一个小例子但它背后的模式可以扩展出很多实际功能把 reducer 从组件文件里单独抽出去放到reducers/cartReducer.js配合单测覆盖每个 action非常爽。我在项目里就用 vitest 对 reducer 写过几十个用例每个 case 一两个 it把各种边界条件空车、数量为 1 再减、重复撤销到底全部钉死。把 items 初始化改为从接口加载加载完成后 dispatch 一个SET_ITEMSaction就实现了数据回填 历史干净的效果。如果商品支持优惠券优惠券逻辑是叠加计算还是互斥计算天然适合放在 reducer 里处理因为它的动作类型是明确的一小撮。4. useReducer 在异步场景下的使用实践从在 reducer 里请求到请求放在哪异步处理是 useReducer 实践里最容易让人纠结的地方。Redux 社区早就验证过reducer 必须是纯函数不能在里面请求接口。但 useReducer 没有官方配套的中间件很多人复制 Redux 的习惯放一个 thunk 又觉得重不放又不知道怎么处理 loading、success、error 三个状态。我先给结论在组件或自定义 Hook 里发起异步请求然后 dispatch 不同的 action 通知 reducer 当前处于什么阶段loading / success / error这是最通用、最贴合 useReducer 心智的方案。4.1 一个典型的异步请求流程怎么写以用户登录为例。状态字段包括statusidle / loading / success / error、userInfo、errorMessage。用 useReducer 管理function authReducer(state, action) { switch (action.type) { case LOGIN_START: return { ...state, status: loading, error: null }; case LOGIN_SUCCESS: return { ...state, status: success, user: action.payload }; case LOGIN_FAILURE: return { ...state, status: error, error: action.payload }; case LOGOUT: return { ...state, status: idle, user: null }; default: return state; } }组件内部的登录函数async function handleLogin(username, password) { dispatch({ type: LOGIN_START }); try { const user await loginApi(username, password); dispatch({ type: LOGIN_SUCCESS, payload: user }); } catch (err) { dispatch({ type: LOGIN_FAILURE, payload: err.message }); } }这个写法的好处一眼就能看出来loading、success、error 三个状态被完整建模了不会出现请求进行中用户又点了一次登录时 loading 状态错乱的问题组件层看起来就是一个瞬时的 dispatch没有任何中间状态需要手动 sync。缺点也明显每次写一个接口调用都要手动写三个 dispatch模板代码有点多。但我更倾向于显式比隐式好——可读性和可调试性胜过一点模板代码。4.2 要不要自己封装一个简单的 async action helper如果你的项目里大量使用 useReducer 处理异步可以封装一个非常轻量的辅助函数不用引入第三方库function createAsyncDispatcher(type, promiseCreator) { return async function (dispatch, payload) { dispatch({ type: ${type}_START, payload }); try { const result await promiseCreator(payload); dispatch({ type: ${type}_SUCCESS, payload: result }); return result; } catch (err) { dispatch({ type: ${type}_FAILURE, payload: err.message }); throw err; } }; } // 使用示例 const fetchUserDispatcher createAsyncDispatcher(FETCH_USER, fetchUserApi); async function loadUser(userId) { try { await fetchUserDispatcher(dispatch, { userId }); } catch (e) { // 已经由 FAILURE action 处理状态这里可以忽略或做额外处理 } }这种模式本质上是手动实现了一个简化版的 thunk。我测试下来在中小型项目里完全够用而且比引入 Redux Toolkit 轻得多。不过要提醒一点不要把异步逻辑放进 reducer 里。比如在 reducer 的LOGIN_STARTcase 里去调用loginApi然后等结果回来再 dispatch 另外一个 action——这种写法破坏了 reducer 的纯函数特性会导致难以追踪的状态变更、重复执行、以及 React StrictMode 下 double-invoke 引发的隐患StrictMode 在开发环境会故意多次调用 reducer 来检查纯函数性如果你在里面发请求会被调用两次逻辑直接炸掉。4.3 竞态条件一个容易被忽略的坑异步操作还有一个常见问题是竞态条件race condition即用户快速触发多次请求后发出的请求先返回导致最终展示的数据是旧请求的结果。useReducer 本身不解决这个问题需要你在 dispatch 之前做校验或者在 effect 里用 AbortController 取消过期请求。我处理过的实际场景是搜索框用户输入React又快速改成Reducer网络慢的话第一次请求可能比第二次后返回。如果直接 dispatchSEARCH_SUCCESS界面就会显示Reducer的关键词却对应React的搜索结果搜索词和结果对不上用户会觉得很奇怪。解决方案是在 effect 里做一个简单的过期标记useEffect(() { let ignore false; async function fetchResults() { dispatch({ type: SEARCH_START }); const results await searchApi(keyword); if (!ignore) { dispatch({ type: SEARCH_SUCCESS, payload: results }); } } fetchResults(); return () { ignore true; }; }, [keyword]);cleanup 函数把ignore置为 true意味着组件卸载或 keyword 再次变化时旧请求即使返回了也不会再 dispatch 任何 action。这个模式配合 useReducer 的状态管理非常顺滑——reducer 只管状态怎么变而这个请求还该不该更新状态由调用方控制职责清晰。5. useReducer useContext打造一个不需要第三方库的轻量全局状态方案我经常被问到项目状态共享到底选 Redux 还是 Zustand 还是 Context useReducer。我的回答是如果你的需求主要是多组件共享某个领域状态、状态变更逻辑有明确规则、不想为一个小模块引入大而全的全局状态库那 useReducer useContext 完全能胜任。5.1 组合的完整代码模式以一个用户偏好设置为例涉及到主题模式、字体大小、语言三项设置多个组件设置面板、文章页、导航栏都要读取和修改。先定义 Context 和 Providerimport { createContext, useContext, useReducer } from react; const SettingsContext createContext(null); function settingsReducer(state, action) { switch (action.type) { case SET_THEME: return { ...state, theme: action.payload }; case SET_FONT_SIZE: return { ...state, fontSize: action.payload }; case SET_LANGUAGE: return { ...state, language: action.payload }; case RESET: return { ...state, theme: light, fontSize: 14, language: zh-CN }; default: return state; } } const initialState { theme: light, fontSize: 14, language: zh-CN }; export function SettingsProvider({ children }) { const [state, dispatch] useReducer(settingsReducer, initialState); return ( SettingsContext.Provider value{{ state, dispatch }} {children} /SettingsContext.Provider ); }组件内部读取和更新function SettingsPanel() { const { state, dispatch } useContext(SettingsContext); return ( div select value{state.theme} onChange{(e) dispatch({ type: SET_THEME, payload: e.target.value })} option valuelight浅色/option option valuedark深色/option /select input typerange min12 max24 value{state.fontSize} onChange{(e) dispatch({ type: SET_FONT_SIZE, payload: Number(e.target.value) })} / button onClick{() dispatch({ type: RESET })}恢复默认/button /div ); }所有需要共享设置的组件都可以通过useContext(SettingsContext)拿到统一的 state 和 dispatch。状态变更完全由 reducer 控制不会出现在 A 组件改了 localStorage 但 B 组件不知道的同步问题。5.2 性能注意事项不瞎优化但也不用摆烂Context useReducer 的性能一直是讨论热点。每次 state 更新Provider 的 value 是一个新对象所有消费了这个 Context 的组件都会重新渲染。这是 Context 的固有行为不是 useReducer 的锅。性能优化的几个实用建议按领域拆分 Context。不要把所有全局状态塞进一个巨型 Context。比如把用户信息和主题设置拆成两个 Provider主题切换时用户信息相关的组件不会受影响。把 Context value 用 useMemo 包裹。这样只有当 state 真正变化时才生成新的 value 对象。const value useMemo(() ({ state, dispatch }), [state, dispatch]);因为 dispatch 本身稳定这个 useMemo 实际等价于[state]能减少一部分无意义的子组件重渲染。用 selector 模式裁剪 Consumer。如果只有一个组件需要状态里的theme字段而另一个组件只需要fontSize可以自己写一个小的 useSelector 样式封装。不过对于中小型项目我建议先别过度设计等真的出现性能瓶颈或者能明显感知页面卡顿再拆。dispatch 函数的稳定性是最大加分项。因为 dispatch 在整个生命周期不变子组件即使每次都重新渲染也只有在事件触发时才会拿到新的 action 对象依赖 dispatch 的 useMemo、useEffect 都不会被频繁重建这点比直接在 Context 里传一堆回调函数要克制得多。5.3 什么时候该升级到 Redux 或 Zustand我自己会遵守几个判断标准状态是全局性的、跨多个页面、更新频率高比如用户实时位置、在线状态、播放列表需要 DevTools 时间旅行调试、持久化中间件、请求缓存等 Redux 生态能力团队成员对 Redux 的模式更熟悉维护成本反而更低状态逻辑足够复杂需要引入实体关系、规范化存储normalized state等概念如果只是上面购物车、设置的规模useReducer Context 完全绰绰有余。引入一个全局状态库的成本不只是包体积还有团队关于什么时候该 dispatch、什么时候该用 selector、action 怎么命名的规约成本。能用原生 Hooks 解决的先用原生 Hooks 解决这是我在实际项目中反复验证过的稳妥路线。6. 我在生产环境里踩过的坑与排查方法useReducer 用起来比 useState 稍微复杂坑也更多。这一节我把生产环境里真正踩过的几个坑整理成完整的排查链路分享我当时的排查过程和最终修复方案希望你能直接避雷。6.1 坑一reducer 里不小心做了副作用导致 StrictMode 下状态多算一次现象开发环境下counter 每次点击 1数字却变成 2。用户一脸懵我也一脸懵。排查过程我先检查是不是 onClick 绑定出了问题后来注释掉 StrictMode 发现数字恢复正常。这时我意识到 React 在开发环境的 StrictMode 下会故意调用两次 reducer和两次 render目的就是把 impure reducer 的问题提前暴露出来。我把counterReducer打开一看里面竟然写了一个console.log和localStorage.setItem——这俩都是副作用在 StrictMode 下被执行两次导致一些外部状态被重复写入表现就是数字变化异常。修复方案把副作用从 reducer 里全部挪走。持久化操作用 useEffect 监听 state 变化统一处理日志也移到组件层。reducer 只保留纯粹的state 转换逻辑。这个坑我印象极深因为它不是 error而是看起来正常但结果不对的类型非常难定位。排查到的核心思路是只要发现开发环境行为和生产环境不一致优先怀疑 StrictMode 和 impure reducer 的组合。6.2 坑二初始化函数 init 里用了组件的 props但 props 更新后状态却没有跟着变现象某个筛选组件父组件传入defaultFilterprops子组件第一次渲染时用它初始化 state。父组件更新 props 后子组件状态没有重置筛选条件停留在旧值。排查过程一开始我以为 useReducer 的 initialArg 变化会自动触发重新初始化查了文档才知道initialArg只在首次渲染时用一次后续 props 变化并不会重置 reducer 状态。很多人会把 reducer 当成响应式的state computeFromProps模型其实它是一次性初始化 事件驱动更新的模型。修复方案要看产品预期是什么——如果 props 变化时确实想重置状态需要在组件里手动处理useEffect(() { dispatch({ type: RESET_FROM_PROPS, payload: { defaultFilter: defaultFilterProp } }); }, [defaultFilterProp]);或者直接用key{newKey}强制整个组件重新挂载但成本较高。我当时选择了第一种并且把RESET_FROM_PROPS定义成 reducer 里的一个显式 action逻辑清晰以后也好测试。6.3 坑三dispatch 传入的 action 对象被误当成可变对象多次修改导致 reducer 内部出现怪异分支现象我写过一个批量操作功能事件处理里先buildAction()构造一个 action然后在某个循环里给这个 action 添加额外字段最后 dispatch 出去。结果 reducer 里对同一 action 走到了完全错误的 case排查了一整个下午。排查过程后来发现我在循环里action.payload.count ...这种写法导致同一个 action 对象在 reducer 内部被重复读取时 payload 已经变了switch 判断的 type 没有变但分支里的计算全部基于被改过的 payload结果自然不对。修复方案action 对象也应当被视为不可变对象。要修改就新建对象不要复用。我后来把所有构造 action 的逻辑统一改成显式返回新对象dispatch({ type: ACTIONS.BATCH_SET, payload: { ids, quantity: newQuantity }, });并且给自己立了个规矩dispatch 出去的 action不要再碰它也不要试图在事件处理函数里 mutate 它。这条规矩让异步回调里的 action 构造也安全了很多。6.4 坑四错误地把派生状态存进 reducer导致状态不一致现象购物车例子中我一开始把totalPrice作为一个独立字段存在 state 里每次增减商品时都手动计算并更新。后来新增了批量设置数量的 action忘记更新 totalPrice页面上总数对不上。用户反馈明明 5 件商品但总价显示的是 4 件的钱。排查过程追踪 state 发现items正确totalPrice是旧值。这个 bug 的本质是冗余状态derived state 被重复存储破坏了单一数据源原则。因为如果每个 action 都要记得更新 totalPrice迟早有遗漏。修复方案把 totalPrice 从 state 中移除在组件层用useMemo或直接reduce计算const totalPrice useMemo( () state.items.reduce((sum, item) sum item.price * item.quantity, 0), [state.items] );这不仅是重构更是一个值得记住的设计原则能让 React 自动推导的状态就不要让 reducer 手动维护。6.5 坑五撤销功能里用了push而不是concat导致历史栈状态被污染现象实现撤销时我用history.push(state.items)把当前 items 推入历史栈。第一次撤销正常第二次撤销时发现回到了一个中间态而不是最初态。排查过程问题出在push会原地修改数组而这个数组正是当前 state.items 的引用。当我在后续操作中基于同一数组修改时历史栈里存的引用也被改了历史变成了可变历史。修复方案一律用不可变操作history: [...state.history, state.items]这个坑特别隐蔽因为 JavaScript 数组的push返回新长度而不是新数组很容易让人忽略它修改的是原数组。凡是和不可变数据打交道的地方都要养成用concat/展开运算符 的习惯。6.6 排查思路小结我在踩了这些坑之后总结了一套流程分享给你作为参考先看 StrictMode 下是否复现复现则优先怀疑 reducer 不纯再确认 action 载荷是否在 dispatch 前后被意外改动看一下是否有字段违反单一数据源原则翻一下是否有类似push的原地修改操作最后检查初始化逻辑里是否依赖了后续 props 的变化这套顺序基本覆盖了 useReducer 90% 的常见问题建议你遇到异常的时候照着走一遍比打印一堆日志来得快。7. useReducer 面向 TypeScript 的实战姿势用 Discriminated Union 约束所有裸奔的 action如果你的项目用了 TypeScriptuseReducer 会变得更香——因为 error 可以从运行时才发现提前到编译时就被拦截。这是我目前最推荐的一节也是很多人没用好 useReducer 的原因。7.1 一个标准的 Discriminated Union action 写法关键思想把所有可能的 action 类型定义为一个联合类型每种 action 通过type字面量区分同时用 TypeScript 收窄narrowing让每个 case 里都能正确推断 payload 的类型。type UserState { user: { id: string; name: string } | null; status: idle | loading | success | error; error: string | null; }; type UserAction | { type: FETCH_USER_START } | { type: FETCH_USER_SUCCESS; payload: { id: string; name: string } } | { type: FETCH_USER_FAILURE; payload: string } | { type: LOGOUT }; function userReducer(state: UserState, action: UserAction): UserState { switch (action.type) { case FETCH_USER_START: return { ...state, status: loading, error: null }; case FETCH_USER_SUCCESS: return { ...state, status: success, user: action.payload }; case FETCH_USER_FAILURE: return { ...state, status: error, error: action.payload }; case LOGOUT: return { ...state, user: null, status: idle }; default: // 这里推荐用 exhaustive check确保所有分支都被覆盖 return state; } }注意这行代码return state前面的 default。TS 里如果你把所有 action 分支都写完了default 分支实际上是不可达的。你可以用exhaustive技巧让它编译报错function assertNever(x: never): never { throw new Error(Unexpected object: x); } function userReducer(state: UserState, action: UserAction): UserState { switch (action.type) { ... default: return assertNever(action); } }这样如果有人给UserAction加了新类型但忘了写 caseTS 会直接报错而不是等运行时才出问题。这是我强烈推荐的一个小技巧能帮团队省下大量漏写分支的 debug 时间。7.2 把 reducer 单独抽出来做单元测试的体验reducer 因为是纯函数测试体验可以说是 React 状态管理方案里最好的之一。我用 vitest 写过下面这样的测试import { describe, it, expect } from vitest; import { userReducer, initialState } from ./userReducer; describe(userReducer, () { it(should handle FETCH_USER_SUCCESS, () { const state userReducer(initialState, { type: FETCH_USER_SUCCESS, payload: { id: 1, name: 张三 }, }); expect(state.status).toBe(success); expect(state.user).toEqual({ id: 1, name: 张三 }); }); it(should handle FETCH_USER_FAILURE, () { const state userReducer(initialState, { type: FETCH_USER_FAILURE, payload: 网络错误, }); expect(state.status).toBe(error); expect(state.error).toBe(网络错误); }); });写这类测试几乎没有成本因为不需要 mock 任何 DOM、HTTP 或组件。回购车、撤销、重置这些业务规则时我都是先把 reducer 的测试写好再写组件测试先行让重构安全感大大提高。很多前端项目不写测试不是不想写而是组件测试成本太高useReducer 恰好把逻辑和视图切得很干净是测试性价比最高的抓手。7.3 reducer 文件结构怎么组织才不乱实际项目里当 action 类型变多我习惯把 reducer 拆成这样features/ cart/ reducer.ts actions.ts types.ts useCart.ts CartEditor.tsx其中types.ts放CartState、CartAction等类型定义actions.ts放 action creator 函数目的是提供类型安全且方便调用的 dispatch 参数reducer.ts放纯函数 initialStateuseCart.ts是一个自定义 Hook将 useReducer、派生状态和事件方法都包装起来组件层只消费useCart()自定义 Hook 的长相大概是function useCart() { const [state, dispatch] useReducer(cartReducer, undefined, createInitialCart); const totalPrice useMemo( () state.items.reduce((sum, item) sum item.price * item.quantity, 0), [state.items] ); const addItem useCallback((item: CartItem) { dispatch({ type: ADD_ITEM, payload: item }); }, []); const removeItem useCallback((id: string) { dispatch({ type: REMOVE_ITEM, payload: { id } }); }, []); return { state, totalPrice, addItem, removeItem, dispatch }; }这样组件里就不再出现dispatch({ type: ACTIONS.REMOVE_ITEM, payload: { id }})这种细碎代码而是调removeItem(id)语义更清晰也方便在 Hook 层统一处理派生状态。这个模式我愿称之为 useReducer 的终极形态reducer 管状态规则、useMemo 管派生状态、useCallback 管事件方法、组件只管渲染。8. 写在最后useReducer 的真实定位与我的使用建议我在不同规模的项目里试过各种状态方案最后给 useReducer 的定位是它是 React 原生状态管理里规则化与轻量之间的最佳平衡点。它比 useState 多了一层action 语义让状态变化有了名字和规则代码可读性和可维护性明显提升它比 Redux 少了中间件生态和全局单例正因为轻所以反而更容易被理解和被掌控。它不是万能的复杂到一定程度该上 Redux/Zustand 还是要上但作为日常开发的主力状态方案它非常靠谱。如果你现在正处在要不要从 useState 换成 useReducer的纠结里我给个简单的判断方法打开你的组件文件数一下setState的数量和它们之间的联动关系。超过三个且联动明显或者你发现自己在事件处理函数里写了既要改 A 又要重置 B 还要清空 C那今天就动手试试 useReducer 吧。别担心多出来的模板代码——几乎所有从 useState 切到 useReducer 的人清理完几个组件后都会有种以前怎么没想到的畅快感。最后再分享一个小技巧如果你想让 useReducer 的调试体验更顺滑可以在 dispatch 外面包一层日志函数把 action 打出来配合 React DevTools 的 reducer 状态追踪线上出 bug 时定位效率会快很多。当然这层日志只用放在开发环境生产环境记得去掉。用 useReducer 最大的快乐从来不是代码少了几行而是当状态逻辑越来越庞杂时你依然能一眼看穿它每一步是怎么走到这里的。
