在 React 项目中使用 Redux 时，不少人都遇到过调用 dispatch 之后组件状态完全没有变化的情况。表面上看代码逻辑没有问题，action 也发出了，但界面就是不动。这类问题通常并不复杂，只是数据流中的某些约定被忽略了。
一、为什么 dispatch 之后状态没有更新
Redux 的核心机制要求 store 只能通过 reducer 返回的新状态来触发更新。如果 reducer 返回的对象和之前的 state 指向同一个引用地址，即便里面的字段被改了，React 绑定的订阅也无法感知变化。很多初学者会在 reducer 里直接操作参数，例如修改数组或对象属性，这破坏了纯函数规则。
另一个高频原因是 action 的 type 不匹配。dispatch 时发出的 type 是 USER_LOGIN，但 reducer 里判断的却是 USER_LOGIN_SUCCESS，这样 switch 分支根本不会命中，返回的是默认的旧 state。此外，如果使用了 redux-thunk 等中间件却没有在 store 中正确配置，函数类型的 action 会被原样透传，也不会产生状态变更。
1.1 Reducer 直接修改原 state 的示例
下面这段代码展示了错误写法：在 reducer 中直接 push 数组，返回的是被修改过的原 state 引用。
const initialState = {
list: []
};
function todoReducer(state = initialState, action) {
switch (action.type) {
case 'ADD_TODO':
// 错误：直接修改原 state.list，引用未变
state.list.push(action.text);
return state;
default:
return state;
}
}
由于 push 操作改变了原数组，但 state 对象本身还是原来的引用，React-Redux 的浅比较认为状态没变，因此不会重新渲染。正确的做法总是返回新的对象和数组。
1.2 正确的不可变更新写法
使用展开运算符或数组方法来生成新引用，才能保证更新被检测到。
const initialState = {
list: []
};
function todoReducer(state = initialState, action) {
switch (action.type) {
case 'ADD_TODO':
// 正确：返回新对象和新数组
return {
...state,
list: [...state.list, action.text]
};
default:
return state;
}
}
这种写法创建了全新的 list 数组，Redux 订阅者拿到的新 state 与旧 state 引用不同，更新通知得以正常发出。在复杂嵌套结构中，也可以借助 immer 库来简化不可变操作。
二、Action 与 Reducer 匹配排查
当 dispatch 无效时，第一步应当确认 action 是否真的被 reducer 处理。可以在 reducer 入口打印 action.type，或者直接使用 Redux DevTools 查看 action 日志。如果 action 出现了但 state 没变，基本就是 type 不匹配或分支遗漏。
此外，使用常量管理 action type 能有效避免拼写错误。把类型定义集中到一个文件，action creator 和 reducer 都引用同一份常量，可以从源头消灭字符串不一致的问题。
2.1 使用常量统一类型
下面的示例将类型提取为常量，降低耦合和出错概率。
// actionTypes.js
export const ADD_TODO = 'ADD_TODO';
// actions.js
import { ADD_TODO } from './actionTypes';
export const addTodo = (text) => ({ type: ADD_TODO, text });
// reducer.js
import { ADD_TODO } from './actionTypes';
function todoReducer(state = { list: [] }, action) {
switch (action.type) {
case ADD_TODO:
return { ...state, list: [...state.list, action.text] };
default:
return state;
}
}
通过这种方式，如果常量名写错，构建阶段或 IDE 就会提示，而不再是运行时默默失效。对于大型项目，配合 TypeScript 还能进一步约束 action 结构。
三、Store 配置与中间件问题
如果使用了异步 action（返回函数的 thunk），但创建 store 时忘记应用中间件，dispatch 一个函数会被当作普通对象处理，导致没有任何状态变化。检查 store 配置是否包含对应的 enhancer 非常关键。
另外，多个 reducer 合并时如果 key 写错，也会导致状态挂在错误的节点上，组件读取的位置和实际更新的位置不一致，看起来就像 dispatch 无效。
3.1 正确配置中间件
以下代码展示如何使用 redux-thunk 创建 store。
import { createStore, applyMiddleware, combineReducers } from 'redux';
import thunk from 'redux-thunk';
import todoReducer from './reducer';
const rootReducer = combineReducers({
todo: todoReducer
});
const store = createStore(
rootReducer,
applyMiddleware(thunk)
);
export default store;
配置完成后，dispatch 一个返回函数的 action 就能在内部继续 dispatch 普通 action，从而更新状态。如果这里漏掉 applyMiddleware(thunk)，函数型 action 不会被执行，界面自然不会变化。
四、调试与排查清单
遇到 dispatch 无效，建议按固定顺序排查：先确认 action 是否发出、类型是否正确；再检查 reducer 是否返回新引用；最后验证 store 和中间件配置。Redux DevTools 可以直观对比每次 dispatch 前后的 state 差异。
也可以临时在容器组件里打印 useSelector 取到的值，确认订阅的数据路径是否和 reducer 挂载的路径一致。多数情况下，状态未更新并不是 Redux 本身的缺陷，而是上述约定被打破。
4.1 快速自查表
- reducer 是否直接修改了原 state 对象或数组
- action.type 与 reducer 中的 case 是否完全一致
- store 是否通过 combineReducers 正确挂载状态分支
- 异步 action 所需的中间件是否已应用
- 组件读取状态的 selector 路径是否匹配 store 结构
把这张清单过一遍，基本能定位九成以上的 dispatch 无效问题。保持 reducer 纯函数、统一 action 类型、规范 store 配置，是稳定使用 Redux 的基础。