1. 这不是“读源码”而是搞懂 Redux 的心脏协同机制你打开 Redux 官方文档看到combineReducers和bindActionCreators这两个 API第一反应可能是“哦一个用来合并 reducer一个用来绑定 action creator”——然后就去抄示例代码了。但真正用过半年以上 Redux 的人很快会发现当项目状态树变深、模块拆分变多、异步逻辑开始嵌套时combineReducers报的undefined错误、bindActionCreators返回函数调用后 state 没更新、甚至dispatch被包裹两层后丢失this上下文……这些问题根本不会在文档里写也不会在 TypeScript 类型提示里暴露。它们藏在combineReducers对 key 的严格校验逻辑里藏在bindActionCreators内部对函数签名的隐式假设中更藏在createStore初始化时与combineReducers返回的 root reducer 之间那一次关键的reducer(state, { type: redux/INIT })调用里。我带过三个前端团队从电商后台到低代码平台所有用 Redux 的项目都卡在同一个节点能跑通 demo但改一行 reducer 就连锁报错能写同步逻辑但一加thunk或saga就 dispatch 失效。根子不在 middleware而在combineReducers和bindActionCreators这两个看似“辅助”的函数身上。它们不是语法糖而是 Redux 状态流的调度中枢和契约守门员。combineReducers实际上定义了整个应用的状态结构协议——它强制要求每个子 reducer 必须处理redux/INIT必须对未知 action type 返回当前 state而非undefined必须把state当作不可变值来对待而bindActionCreators则悄悄完成了函数调用语义到dispatch语义的翻译它不改变 action creator 的输入输出却让调用者彻底忘记dispatch的存在代价是它必须精确识别“纯函数”边界一旦传入箭头函数、类方法或带闭包的函数就会在绑定时或调用时暴露出this绑定失效、参数透传异常等底层问题。这篇文章不讲“怎么用”只讲“为什么这样设计”、“不这样写会掉进什么坑”、“调试时该盯哪几行代码”。我会带着你逐行拆解combineReducers的 87 行核心实现不含注释和空行还原它如何用Object.keys(reducers)构建状态树骨架、如何用hasOwnProperty做 key 安全校验、如何在undefined状态下触发警告却不中断执行也会带你走进bindActionCreators的 42 行精简逻辑看它如何用typeof fn function做类型守门、如何用bind(null, dispatch)解耦this、又如何用递归遍历对象属性实现深度绑定。这不是源码“翻译”而是还原 Redux 设计者在 2015 年那个深夜写下这两段代码时的真实权衡性能与安全的平衡、灵活性与约束性的拉锯、以及对 JavaScript 函数式特性的极致信任与谨慎防范。2. combineReducers状态树的宪法制定者与执行法官2.1 它到底做了什么三句话说清本质combineReducers不是一个“合并工具”而是一个状态结构编译器。它的输入是一组命名的 reducer 函数如{ user: userReducer, cart: cartReducer }输出是一个全新的、符合 Redux 协议的 root reducer 函数。这个新函数接收(state, action)但它内部的执行逻辑完全由输入 reducer 的 key 名称驱动第一它定义了 state 的形状shape输出的 state 对象的 key 必须且只能是输入对象的 key。如果你传入{ user: fn, cart: fn }那么state.user和state.cart就是合法路径state.profile或state.items就是非法访问——这不是运行时报错而是在开发时通过warning提前预警。第二它实现了状态的“分片隔离”当action.type为USER_LOGIN_SUCCESS时只有userReducer会被调用cartReducer完全不参与本次计算反之亦然。这种隔离不是靠switch分支实现的而是靠reducers[action.type]的动态查找完成的因此它天然支持任意数量的模块且新增模块无需修改现有 reducer。第三它强制执行“无副作用”契约每个子 reducer 在收到未知type时必须返回其当前state不能返回undefined否则combineReducers会在控制台抛出明确警告“Unexpected undefined returned from a reducer...”并给出具体是哪个 key 的 reducer 出了问题。这个警告不是装饰而是防止状态树某一分支意外坍塌的核心防线。提示很多人以为combineReducers是为了“组织代码”这是严重误解。它的核心价值在于将状态结构的定义权从开发者手中收归框架用运行时检查代替人工约定。没有它你得自己写switch (action.type)手动维护state各字段的初始化值和更新逻辑稍有疏忽就会导致state.cart变成undefined进而引发后续所有依赖cart的组件渲染崩溃。2.2 深度拆解87 行代码里的 5 层防御机制我们以 Redux v4.3.0 的combineReducers.js为蓝本这是目前最稳定、被广泛 fork 的版本逐层解析其核心逻辑。注意以下所有代码片段均来自真实源码仅删减了 JSDoc 注释和空行保留全部逻辑主干。第一层输入校验与键名预处理export default function combineReducers(reducers) { const reducerKeys Object.keys(reducers); const finalReducers {}; for (let i 0; i reducerKeys.length; i) { const key reducerKeys[i]; if (process.env.NODE_ENV ! production) { if (typeof reducers[key] undefined) { warning(No reducer provided for key ${key}); } } if (typeof reducers[key] function) { finalReducers[key] reducers[key]; } }这段代码做了三件事Object.keys(reducers)获取所有 key这是构建状态树骨架的第一步遍历每个 key用typeof reducers[key] function做类型过滤自动忽略非函数值如字符串、数字、null这让你可以在开发时临时注释掉某个 reducercart: null而不导致整个应用崩溃在非生产环境对undefined值发出warning但不 throw error保证开发体验流畅。注意这里finalReducers是一个纯净的对象副本它剥离了所有非函数属性。这意味着如果你在reducers对象里写了const reducers { user, cart, version: 1.0 }version字段会被静默丢弃state中永远不会出现state.version。这不是 bug而是设计——combineReducers只关心“可执行的 reducer”其他都是元数据应放在别处管理。第二层状态初始化与redux/INIT的特殊处理let shapeAssertionError; try { Object.keys(finalReducers).forEach(key { finalReducers[key](undefined, { type: ActionTypes.INIT }); }); } catch (e) { shapeAssertionError e; }这是combineReducers最反直觉也最关键的一步。它在返回最终 reducer 之前主动调用每一个子 reducer传入(undefined, { type: redux/INIT })。目的只有一个验证每个子 reducer 是否能正确处理初始状态。如果某个子 reducer 写成return state || initialState那么传入undefined时会返回initialState一切正常但如果写成return { ...state, data: action.payload }传入undefined时就会报Cannot read property data of undefinedshapeAssertionError就会捕获这个错误这个错误不会被吞掉而是在后续combinedReducer执行时被重新抛出并附带清晰的上下文“The slice reducer for key cart returned undefined when called with an action of type redux/INIT”。实操心得我在某电商项目中遇到过一个经典陷阱——cartReducer里用了immer的produce但忘了给produce的第一个参数传默认值produce(state || initialState, draft {...})。结果produce(undefined, ...)直接返回undefined导致整个cart分支初始化失败。combineReducers的这层预检让我在yarn start的瞬间就定位到了问题而不是等到用户点击“加入购物车”才报错。第三层主 reducer 函数的生成与状态分发逻辑return function combination(state {}, action) { if (shapeAssertionError) { throw shapeAssertionError; } let hasChanged false; const nextState {}; for (let i 0; i reducerKeys.length; i) { const key reducerKeys[i]; const reducer finalReducers[key]; const previousStateForKey state[key]; const nextStateForKey reducer(previousStateForKey, action); if (typeof nextStateForKey undefined) { const errorMessage getUndefinedStateErrorMessage(key, action); throw new Error(errorMessage); } nextState[key] nextStateForKey; hasChanged hasChanged || nextStateForKey ! previousStateForKey; } return hasChanged ? nextState : state; };这才是combineReducers的心脏。它返回的combination函数就是你传给createStore的 root reducer。我们重点看三个细节状态不可变性保障nextState是一个全新对象nextState[key] nextStateForKey是浅拷贝赋值。Redux 不要求 deep clone只要求每个 key 的值是新的引用。所以userReducer返回新对象cartReducer返回新对象nextState就是新对象state原始引用被完整保留。变更检测优化hasChanged变量记录是否有任何子状态发生变更。如果所有nextStateForKey previousStateForKey则直接返回原始state避免无谓的引用替换。这为 React 的PureComponent或React.memo提供了可靠的 shallowEqual 基础。undefined的零容忍if (typeof nextStateForKey undefined)这行判断是 Redux “契约精神”的终极体现。它不接受任何模糊地带——子 reducer 必须显式返回一个值即使是null或0undefined是非法状态必须立即中断执行并报错。这个设计杜绝了“忘记 return”这类低级错误在深层嵌套中悄然传播。第四层开发模式下的额外保护warning与assertif (process.env.NODE_ENV ! production) { const expectedStateShape {}; Object.keys(finalReducers).forEach(key { expectedStateShape[key] typeof finalReducers[key] function ? finalReducers[key](undefined, { type: ActionTypes.INIT }) : undefined; }); // ... 后续还有对 state 结构的 runtime assertion }在非生产环境combineReducers还会做一次“结构快照”它调用每个 reducer 的INIT生成一个expectedStateShape然后在每次combination(state, action)执行时用assert库检查state的 key 是否与expectedStateShape完全一致。如果state多了一个tempData字段比如某个中间件不小心挂上去的或者少了一个user字段某个 reducer 初始化失败都会触发warning“Unexpected keys tempData found in preloadedState argument passed to createStore.”。注意这个检查只在开发时生效生产环境完全移除零性能损耗。但它让团队协作变得极其清晰——每个人都知道state的合法字段是什么不需要翻文档控制台警告就是最权威的契约。第五层对replaceReducer的兼容性设计combineReducers返回的combination函数还必须支持store.replaceReducer(newRootReducer)。这意味着它不能持有任何闭包状态所有逻辑必须基于传入的state和action计算。源码中没有任何let cachedState或const memoizedResult完全符合 Redux “reducer 必须是纯函数”的最高原则。2.3 常见误用场景与修复方案误用场景具体表现根本原因修复方案子 reducer 返回undefined控制台报错“Unexpected undefined returned from a reducer...”reducer 内部switch缺少default分支或if/else没有兜底return state在每个 reducer 末尾加return state或用 ESLint 插件redux/redux-saga的no-undefined-reducer-return规则自动检测state初始化值与combineReducers冲突createStore(combineReducers(reducers), { user: { id: 1 } })但userReducer初始化返回{ name: }最终state.user是{ name: }而非{ id: 1 }combineReducers的state {}参数优先级低于preloadedState但子 reducer 的INIT调用会覆盖preloadedState中未声明的字段显式传递preloadedState时确保其结构与combineReducers的 key 完全一致或改用redux-persist的persistReducer做状态恢复动态添加 reducer 导致状态丢失用replaceReducer替换新combineReducers({ ...old, newModule })后newModule的 state 是undefined新combineReducers初始化时newModulereducer 收到INITaction但preloadedState中没有newModule字段导致其返回undefined在replaceReducer前先用store.getState()获取当前 state手动构造preloadedState确保新 module 的初始值存在3. bindActionCreators函数调用的“语法糖”与“契约翻译器”3.1 它解决的真问题是“心智负担”而非“代码长度”初学者常问“dispatch(actionCreator())和boundActionCreator()有什么区别后者只是少写了dispatch两个字” 这是典型的技术表层理解。bindActionCreators的真实价值在于它将命令式编程imperative的dispatch动词翻译成了声明式编程declarative的函数调用名词。想象一个登录流程// 方式一手动 dispatch命令式 const handleLogin () { dispatch({ type: LOGIN_REQUEST }); api.login().then(res { dispatch({ type: LOGIN_SUCCESS, payload: res }); }).catch(err { dispatch({ type: LOGIN_FAILURE, error: err }); }); }; // 方式二使用 bindActionCreators声明式 const { loginRequest, loginSuccess, loginFailure } boundActionCreators; const handleLogin () { loginRequest(); // 我要发起登录请求 api.login().then(res loginSuccess(res)) // 登录成功了 .catch(err loginFailure(err)); // 登录失败了 };表面看只是少了dispatch但心智模型完全不同方式一中dispatch是一个外部操作你需要时刻记住“我现在要触发一个副作用”方式二中loginRequest是一个业务语义函数调用它就代表“登录请求已发出”dispatch已被封装为实现细节你不再需要思考“谁来 dispatch”、“dispatch 给谁”。这就是bindActionCreators的核心契约它让 action creator 从“生成 action 的工厂”升级为“触发状态变更的命令”。而这个升级的代价是它必须对输入函数施加严格的约束。3.2 源码精析42 行里的 3 种绑定策略bindActionCreators的源码比combineReducers更短但逻辑更精巧。我们看其核心实现export default function bindActionCreators(actionCreators, dispatch) { // 情况一传入单个函数 if (typeof actionCreators function) { return bindActionCreator(actionCreators, dispatch); } // 情况二传入函数对象 if (typeof actionCreators ! object || actionCreators null) { throw new Error(bindActionCreators expected an object or a function); } // 创建新对象避免污染原对象 const boundActionCreators {}; for (const key in actionCreators) { const actionCreator actionCreators[key]; if (typeof actionCreator function) { boundActionCreators[key] bindActionCreator(actionCreator, dispatch); } } return boundActionCreators; } function bindActionCreator(actionCreator, dispatch) { return function() { return dispatch(actionCreator.apply(this, arguments)); }; }策略一单函数绑定 ——bindActionCreatorbindActionCreator(actionCreator, dispatch)是原子操作。它返回一个新函数这个新函数apply(this, arguments)保证了actionCreator内部的this和所有参数...args被完整透传dispatch(...)将actionCreator的返回值即 action 对象交给 store 处理整个过程是零侵入的你不需要修改actionCreator的任何一行代码它依然可以独立测试actionCreator(test)返回 action也可以被bindActionCreators包装后使用bound(test)触发 dispatch。注意apply(this, arguments)是关键。如果actionCreator是一个类方法class UserActions { login() { return { type: LOGIN }; } }直接bindActionCreators({ login: userActions.login }, dispatch)会导致this指向undefined。正确做法是bindActionCreators({ login: userActions.login.bind(userActions) }, dispatch)或改用箭头函数login () ({ type: LOGIN })。策略二对象批量绑定 —— 深度遍历与类型过滤当传入{ login, logout }这样的对象时bindActionCreators会创建一个空对象boundActionCreators遍历actionCreators的每个key对每个value做typeof function判断只绑定函数跳过字符串、数字、null、undefined 等所有非函数值将绑定后的函数挂载到boundActionCreators[key]下。这个设计带来了极强的容错性。你可以这样写const actionCreators { login: () ({ type: LOGIN }), logout: () ({ type: LOGOUT }), // version: 1.0, // 这行即使存在也不会报错只是被忽略 // utils: someHelper, // 非函数同样被忽略 }; const bound bindActionCreators(actionCreators, dispatch);策略三错误防御 —— 对非对象/非函数输入的即时拦截if (typeof actionCreators ! object || actionCreators null) { throw new Error(bindActionCreators expected an object or a function); }这个throw是非常必要的。试想如果传入bindActionCreators(not an object, dispatch)函数内部for (key in actionCreators)会遍历字符串的每个字符n,o,t...然后尝试actionCreators[n]结果是undefined再typeof undefined function为false最终返回一个空对象{}。调用者拿到{}后bound.login()就是undefined()报TypeError: undefined is not a function错误信息极其模糊。而现在的throw直接告诉你“你传错了类型”精准定位问题。3.3 实战避坑那些让你抓耳挠腮的绑定失效问题问题一箭头函数的this绑定失效// ❌ 错误箭头函数没有自己的 thisbind 无效 const actions { fetchUser: (id) ({ type: FETCH_USER, id }) }; const bound bindActionCreators(actions, dispatch); bound.fetchUser(123); // 正常工作因为箭头函数不依赖 this // ✅ 但如果你在 action creator 里用了 this const api { baseUrl: /api }; const actions { fetchUser: (id) ({ type: FETCH_USER, url: this.baseUrl /user/ id }) // this 指向 undefined };修复要么改用普通函数fetchUser: function(id) { ... }要么显式绑定thisfetchUser: (id) ({ type: FETCH_USER, url: api.baseUrl /user/ id })。问题二高阶函数HOC返回的函数未被绑定// ❌ 错误createAsyncAction 是一个返回函数的工厂bindActionCreators 不会执行它 const createAsyncAction (type) () ({ type }); const actions { login: createAsyncAction(LOGIN) }; const bound bindActionCreators(actions, dispatch); bound.login(); // 返回的是一个函数不是 action修复bindActionCreators只绑定“函数”不执行“函数”。你需要先执行工厂函数const actions { login: createAsyncAction(LOGIN)() // 立即执行得到 action 对象 }; // 但这失去了异步能力。正确做法是让 createAsyncAction 返回一个可绑定的函数 const createAsyncAction (type) (payload) ({ type, payload });问题三mapDispatchToProps中的bindActionCreators使用时机错误// ❌ 错误在组件内部每次 render 都调用 bindActionCreators const MyComponent ({ dispatch }) { const bound bindActionCreators({ login }, dispatch); // 每次 render 都新建函数 return button onClick{() bound.login()}Login/button; }; // ✅ 正确在 connect 的 mapDispatchToProps 中一次性绑定 const mapDispatchToProps (dispatch) ({ ...bindActionCreators({ login }, dispatch), // 或更推荐直接返回对象让 connect 内部处理 login: () dispatch(login()) });实操心得bindActionCreators的最佳实践位置永远是mapDispatchToProps的返回值或useDispatchHook 的初始化绑定。在组件内部调用不仅浪费性能每次创建新函数还会破坏React.memo的浅比较导致不必要的重渲染。4. 协同作战combineReducers 与 bindActionCreators 如何共同构建 Redux 生态4.1 它们不是孤立的而是状态流的“入口”与“出口”把 Redux 看作一条河流combineReducers是上游的水坝与分流渠它决定河水state分成几股user,cart,ui每条支流有自己的河床reducer水坝combineReducers确保每条支流的水量state独立、可控且总流量root state可预测bindActionCreators是下游的灌溉阀门与喷头它把抽象的“开闸放水”dispatch(action)指令翻译成具体的“给蔬菜浇水”waterVegetables()、“给果树施肥”feedFruitTrees()这样的业务动作农民组件只需按按钮无需知道水从哪来、压力多大。二者协同的关键在于它们共同遵守 Redux 的单向数据流契约combineReducers保证state的结构是扁平的、key 是确定的、更新是隔离的bindActionCreators保证action的触发是语义化的、调用是无副作用的、参数是透明的。没有combineReducersbindActionCreators就像给一个没有河道的地图安装喷头——水action不知道该往哪流没有bindActionCreatorscombineReducers就像一座完美的水坝但农民只能爬到坝顶手动开闸效率极低。4.2 真实项目中的组合模式从单模块到微前端模式一标准单页应用SPA// reducers/index.js import { combineReducers } from redux; import user from ./user; import cart from ./cart; import ui from ./ui; export default combineReducers({ user, cart, ui }); // actions/index.js import * as userActions from ./user; import * as cartActions from ./cart; export { userActions, cartActions }; // components/Login.js import { useDispatch, useSelector } from react-redux; import { userActions } from ../actions; const Login () { const dispatch useDispatch(); // ✅ 推荐直接使用 useDispatch无需 bindActionCreators const login () dispatch(userActions.login()); // ❌ 不推荐在组件内绑定 // const bound bindActionCreators(userActions, dispatch); return button onClick{login}Login/button; };注意在 React-Redux v7.2 中useDispatchHook 已成为主流bindActionCreators的使用频率大幅下降。但它并未过时而是下沉为connect高阶组件和useDispatch内部的实现基石。模式二模块热加载Code Splitting// store/configureStore.js import { createStore, combineReducers, applyMiddleware } from redux; import { injectReducer } from ./injectReducer; const createRootReducer (asyncReducers {}) combineReducers({ ...baseReducers, ...asyncReducers }); const store createStore( createRootReducer(), applyMiddleware(thunk) ); // 动态注入 reducer export const injectReducer (key, reducer) { store.replaceReducer(createRootReducer({ ...store.asyncReducers, [key]: reducer })); store.asyncReducers { ...store.asyncReducers, [key]: reducer }; }; // 在路由组件中 const ProductPage () { useEffect(() { injectReducer(product, productReducer); }, []); // 此时 productReducer 已注入bindActionCreators 可以安全绑定 const bound bindActionCreators({ fetchProduct }, store.dispatch); };这里bindActionCreators的价值凸显当productReducer是动态加载的fetchProductaction creator 的绑定必须在injectReducer之后进行否则dispatch会找不到对应的 reducer。bindActionCreators提供了这种运行时绑定的灵活性。模式三微前端架构下的状态桥接在某大型 SaaS 平台中我们用 Redux 作为主应用的状态中枢子应用独立部署的 React 微前端需要与主应用共享用户信息。方案是主应用暴露store实例和bindActionCreators工具子应用通过window.parent.store获取主 store子应用调用bindActionCreators({ updateUser }, window.parent.store.dispatch)获得可直接调用的updateUser函数子应用内部updateUser({ name: Alice })主应用的userReducer立即响应所有监听user的组件包括主应用和其它子应用同步更新。这种跨域/跨应用的状态同步bindActionCreators是唯一安全的桥梁——它不暴露store内部结构只提供受控的dispatch接口combineReducers则确保主应用的user状态结构是稳定的、可预测的子应用无需关心user下面还有没有profile、settings等子字段。4.3 性能与调试如何在复杂项目中高效追踪性能监控combineReducers的变更检测是你的朋友当页面卡顿时第一个怀疑对象往往是combineReducers。但它的hasChanged逻辑其实非常高效它只做引用比较不 deepEqual它在nextStateForKey ! previousStateForKey为true时就设置hasChanged true无需遍历完所有 key它返回hasChanged ? nextState : state保证了state引用的稳定性。你可以用 Chrome DevTools 的Performance面板录制一次交互然后在Bottom-Up视图中搜索combination看它是否成为热点。如果它耗时过高说明某个子 reducer 执行太慢比如做了同步 IO 或复杂计算问题不在combineReducers而在 reducer 本身。调试技巧bindActionCreators的“断点注入”bindActionCreators返回的函数本质上是dispatch(actionCreator(...args))的包装。你可以在bindActionCreator内部加断点function bindActionCreator(actionCreator, dispatch) { return function() { console.log(Dispatching:, actionCreator(...arguments)); // 加日志 return dispatch(actionCreator.apply(this, arguments)); }; }或者在 Redux DevTools 的Settings Trace中开启它会自动在每次dispatch时打印完整的 action 调用栈清晰显示是哪个boundActionCreator触发的。最后一个小技巧在大型项目中我习惯在bindActionCreators调用后用Object.freeze()冻结返回的对象防止团队成员意外修改const bound Object.freeze(bindActionCreators(actions, dispatch));这样如果有人写了bound.login null在严格模式下会立即报错而不是默默失效。5. 常见问题与排查技巧实录5.1 “combineReducers 报错Unexpected undefined returned from a reducer” —— 逐行排查指南这个错误是 Redux 开发者最常遇到的但错误堆栈往往指向combineReducers内部让人无从下手。以下是系统化排查步骤步骤一确认错误发生在哪个 key错误信息通常长这样Unexpected undefined returned from a reducer for key cart立刻锁定cart这个 reducer 文件。步骤二检查 reducer 的INIT响应打开cartReducer.js找到其定义const cartReducer (state initialState, action) { switch (action.type) { case ADD_TO_CART: return { ...state, items: [...state.items, action.payload] }; case REMOVE_FROM_CART: return { ...state, items: state.items.filter(i i.id ! action.payload) }; default: return state; // ✅ 这行必须存在 } };高频陷阱default分支被注释掉或删除if/else结构中else分支缺失return state使用了immer但忘了produce(state || initialState, ...)导致produce(undefined, ...)返回undefined。步骤三模拟INIT调用复现问题在浏览器控制台手动执行cartReducer(undefined, { type: redux/INIT });如果返回undefined问题确认如果返回{ items: [] }说明 reducer 本身没问题问题可能出在combineReducers的preloadedState与 reducer 初始化逻辑冲突。步骤四检查preloadedState的结构如果你在createStore时传了第二个参数createStore(rootReducer, { user: { id: 1 }, cart: { items: [] } });确保cart字段的值与cartReducer的initialState结构一致。如果cartReducer的initialState是{ items: [], total: 0 }但preloadedState只给了{ items: [] }combineReducers的INIT预检可能会失败。实操心得我建立了一个团队规范——所有 reducer 的initialState必须是const initialState { items: [], total: 0 }这样的字面量禁止用{} || []等动态表达式确保INIT调用的可预测性。5.2 “bindActionCreators 返回的函数调用后state 没更新” —— 5 分钟定位法这个问题往往伴随着“代码没报错但 UI 不变”是最折磨人的。按以下顺序快速排查检查项操作预期结果说明1. 确认 action creator 是否返回有效 actionconsole.log(bound.login())输出{ type: LOGIN, payload: xxx }如果输出undefined或{}说明 action creator 本身有问题2. 确认 dispatch 是否被正确调用在bindActionCreator内部加console.log(dispatch called)控制台有日志如果没有说明绑定失败或函数未被调用3. 确认 reducer 是否处理了该 type在cartReducer的switch前加console.log(cartReducer called with, action.type)日志中出现对应 type如果没有说明combineReducers没把 action 分发给这个 reducer检查action.type拼写4. 确认 state 更新是否产生新引用在 reducer 中console.log(new state, nextState)然后console.log(same ref?, nextState state)same ref? false如果为true说明 reducer 没有返回新对象React