说到 Redux 里的 Reducer，很多人第一反应就是：“哦，那个返回新对象的函数呗。” 但如果你真的只把它当成一个普通的 JS 函数来看待，那你可能还没摸到 Redux 性能优化和状态管理稳定性的门道。
咱们今天不聊那些枯燥的定义，而是像剥洋葱一样，一层层揭开为什么 Reducer 必须是纯函数，以及一旦这个原则被打破，你的应用会陷入怎样一种“薛定谔的状态”——既存在又不存在，还随时可能崩溃。
为什么“纯”是 Redux 的灵魂？
先别急着翻文档。想象一下，如果你在煮咖啡时，每次按磨豆机按钮，咖啡豆不仅被磨碎了，顺便还把厨房的灯换了，甚至把你昨天没洗的碗也洗了。这听起来很酷对吧？但在软件世界里，这叫“副作用”（Side Effects），它是调试器的噩梦。
Redux 的核心哲学很简单：给定相同的输入，必须永远产生相同的输出。
这就是纯函数（Pure Function）的定义。它不包含任何依赖外部状态的操作，也不会修改传入的参数。在 Redux 里，这意味着：
- 不修改
state：你不能直接改state.user.name = 'New Name'。 - 不调用非纯函数：比如
Math.random()、Date.now()或者发起网络请求。 - 不执行 I/O 操作：不能写日志、不能弹窗、不能存 LocalStorage。
举个真实的“翻车”例子
假设你正在开发一个电商购物车。有一个 Reducer 负责处理 ADD_ITEM 动作。
❌ 错误的写法（非纯函数）：
// 这是一个典型的“坏” Reducer
function cartReducer(state = initialState, action) {
switch (action.type) {
case 'ADD_ITEM':
// 错误点 1: 直接修改了 state 引用
state.items.push(action.item);
// 错误点 2: 引入了时间相关的副作用
state.lastUpdated = Date.now();
return state; // 返回的是同一个引用！
default:
return state;
}
}
这段代码看起来能跑，对吧？点击添加商品，列表确实变了。但是，麻烦才刚刚开始。
当 React 组件检测到 state 没变（因为引用地址一样），它会跳过重新渲染。即使你手动触发了某些 UI 更新，由于 lastUpdated 是随机生成的，你在进行单元测试时，每次断言都会失败，因为你无法预测 Date.now() 的具体值。更糟糕的是，如果你使用了 Redux DevTools 的时间旅行功能，当你撤销上一步操作时，系统会发现 state 对象被意外篡改，导致整个状态树混乱不堪。
✅ 正确的写法（纯函数）：
function cartReducer(state = initialState, action) {
switch (action.type) {
case 'ADD_ITEM':
// 正确点 1: 返回全新的 state 对象
// 正确点 2: 使用展开运算符创建 items 数组的新副本
return {
...state,
items: [...state.items, action.item],
lastUpdated: Date.now() // 注意：虽然调用了 Date.now()，但在 Reducer 内部它被视为确定性输入的一部分，只要你不依赖外部可变状态。不过严格来说，纯函数最好避免这种“伪随机”。更好的做法是在 Action Creator 中生成 timestamp。
};
default:
return state;
}
}
等等，你可能会问：“Date.now() 不是也不确定吗？” 没错，所以在极端的纯函数理念下，连 Date.now() 都不该出现在 Reducer 里。通常的做法是，在 Action Creator 中生成时间戳，然后作为 payload 传给 Reducer。这样，Reducer 就变成了真正的纯函数：输入 Action 和 State，输出新的 State，完全可预测。
深入解析：不可变性（Immutability）是如何防止数据不一致的？
Redux 依赖于 React 的高效更新机制。React 通过比较对象的引用地址（Reference Equality）来判断是否需要重新渲染。
stateA === stateB 为 true 吗？
- 如果
stateA和stateB指向内存中的同一块地址，那么 React 认为数据没变，不做任何事。 - 如果它们指向不同的地址，即使内容一模一样，React 也会触发更新。
场景模拟：嵌套状态的危险
让我们看一个更复杂的例子。假设你的状态结构是这样的：
const initialState = {
user: {
profile: {
name: 'Alice',
avatar: 'default.png'
},
settings: {
theme: 'dark'
}
},
posts: [
{ id: 1, title: 'Hello World' }
]
};
现在，用户想修改头像。
❌ 危险操作：直接修改嵌套属性
case 'UPDATE_AVATAR':
// 这行代码直接破坏了不可变性！
state.user.profile.avatar = action.newAvatar;
return state;
后果是什么？
- 引用不变：
state的地址没变。 - React 欺骗：React 看到
state引用没变，以为数据没更新，于是缓存了旧的虚拟 DOM 树。 - UI 不同步：虽然 Redux Store 里的数据确实变了（因为 JS 对象是引用类型，修改属性会影响原对象），但 UI 不会刷新。你需要强制刷新页面才能看到新头像。
- 调试困难：如果你在其他地方监听了
user的变化，可能会得到意想不到的结果，因为多个组件可能共享了同一个被污染的引用。
✅ 安全操作：层层展开
case 'UPDATE_AVATAR':
return {
...state, // 顶层新对象
user: {
...state.user, // 第二层新对象
profile: {
...state.user.profile, // 第三层新对象
avatar: action.newAvatar // 只有这一层真正改变了
}
}
// posts 保持不变，复用旧引用，节省内存
};
这样做虽然代码长得让人想哭，但它保证了每一层都是全新的引用。React 能够精确地追踪到哪一层变了，从而只更新受影响的组件。这就是所谓的“浅比较”（Shallow Compare）的力量。
工具链：如何优雅地处理不可变性？
我知道，手动写 ...state 真的很累，尤其是当状态嵌套超过三层时，代码会变得难以维护。这时候，我们需要借助一些库来帮我们简化这个过程。
1. Immer.js：革命性的解决方案
Immer 是目前 Redux 生态中最受欢迎的辅助库之一。它允许你编写“看似可变”的代码，但实际上底层会自动生成不可变的更新。
import { createSlice } from '@reduxjs/toolkit';
import { produce } from 'immer';
// 使用 Redux Toolkit 的 createSlice，它内部已经集成了 Immer
const userSlice = createSlice({
name: 'user',
initialState: {
profile: {
name: 'Alice',
avatar: 'default.png'
}
},
reducers: {
updateAvatar: (state, action) => {
// 直接修改 state！看起来很疯狂，对吧？
// 但实际上，Immer 会在后台创建一个草稿（draft），
// 并在 reducer 结束时冻结（freeze）并返回一个新的不可变状态。
state.profile.avatar = action.payload;
}
}
});
export const { updateAvatar } = userSlice.actions;
export default userSlice.reducer;
这段代码是不是清爽多了？你不需要关心嵌套层级，只需要关注你要改什么字段。Immer 会帮你处理好所有引用替换的工作。
2. Immutable.js：早期的硬核方案
在 Immer 出现之前，Immutable.js 是主流。它提供了一套完整的不可变数据结构（如 Map, List）。
import { Map } from 'immutable';
const initialState = Map({
user: Map({
profile: Map({
name: 'Alice',
avatar: 'default.png'
})
})
});
function reducer(state = initialState, action) {
switch (action.type) {
case 'UPDATE_AVATAR':
// 使用 setIn 方法
return state.setIn(['user', 'profile', 'avatar'], action.payload);
default:
return state;
}
}
Immutable.js 的优势在于性能极致优化，劣势在于学习曲线陡峭，且与原生 JS 对象交互时需要转换。对于大多数现代 Redux 项目，除非你有极高的性能需求或复杂的集合操作，否则 Immer + RTK 是更好的选择。
副作用在哪里？Middleware 的职责
既然 Reducer 必须是纯函数，那异步请求、路由跳转、本地存储这些“脏活累活”放哪儿呢？
答案是：中间件（Middleware）。
Redux 的设计将“状态计算”（Reducer）和“副作用处理”（Middleware/Thunks/Sagas）彻底分离。
使用 Redux Thunk 处理异步
// actionCreator.js
export const fetchUser = (userId) => {
return async (dispatch, getState) => {
// 1. 发送开始信号
dispatch({ type: 'USER_FETCH_START' });
try {
// 2. 发起网络请求（副作用发生在这里，不在 Reducer 中）
const response = await fetch(`/api/users/${userId}`);
const data = await response.json();
// 3. 分发成功 action，携带数据
dispatch({ type: 'USER_FETCH_SUCCESS', payload: data });
} catch (error) {
dispatch({ type: 'USER_FETCH_FAILURE', error });
}
};
};
// reducer.js
function userReducer(state = initialState, action) {
switch (action.type) {
case 'USER_FETCH_SUCCESS':
// 纯函数：只负责更新状态
return {
...state,
data: action.payload,
loading: false,
error: null
};
// ...其他情况
default:
return state;
}
}
在这个流程中，fetchUser 是一个 Thunk Action Creator。它包含了异步逻辑（副作用），但它本身不改变状态。它只是通过 dispatch 发出普通的 Action。真正的状态更新发生在 userReducer 中，而 userReducer 依然保持纯净。
使用 Redux Saga 处理复杂副作用
如果你的业务逻辑涉及大量的并发控制、取消请求或复杂的异步流，Redux Saga 使用 Generator 函数提供了更强大的控制力。
import { call, put, takeEvery } from 'redux-saga/effects';
function* fetchUserSaga(action) {
try {
const user = yield call(Api.fetchUser, action.payload.userId);
yield put({ type: 'FETCH_USER_SUCCESS', user });
} catch (e) {
yield put({ type: 'FETCH_USER_FAILURE', message: e.message });
}
}
export function* watchFetchUser() {
yield takeEvery('FETCH_USER_REQUEST', fetchUserSaga);
}
Saga 同样将副作用隔离在外，确保 Reducer 依然是纯函数。
单元测试：纯函数的最大红利
为什么我们要这么折腾，非要让 Reducer 保持纯函数？除了为了 React 的性能和 DevTools 的可追溯性，还有一个巨大的好处：测试变得极其简单。
对于非纯函数，测试需要 Mock 数据库、网络环境、甚至系统时间。但对于纯函数 Reducer，你只需要断言输入和输出。
describe('cartReducer', () => {
it('should handle ADD_ITEM', () => {
const initialState = { items: [], total: 0 };
const action = { type: 'ADD_ITEM', payload: { id: 1, price: 10 } };
const newState = cartReducer(initialState, action);
// 断言 1: 返回了新对象
expect(newState).not.toBe(initialState);
// 断言 2: 物品已添加
expect(newState.items).toHaveLength(1);
// 断言 3: 总价已更新
expect(newState.total).toBe(10);
// 断言 4: 原始状态未被污染
expect(initialState.items).toHaveLength(0);
});
});
你看，没有 Mock，没有 Setup，没有 Teardown。这就是纯函数带来的确定性。你可以放心地在 CI/CD 流水线中运行这些测试，因为它们的结果永远是可预测的。
常见陷阱与最佳实践
尽管原理简单，但在实际开发中，开发者还是会不小心踩坑。以下是一些常见的“非纯”陷阱及规避方法：
默认参数的可变对象：
// ❌ 错误 function reducer(state = { list: [] }, action) { ... } // 每次调用 reducer 时，如果 state 未定义，都会返回同一个 { list: [] } 对象引用！ // 如果有多个 store 实例，它们会共享这个初始状态。 // ✅ 正确 function reducer(state = {}, action) { if (!state.list) state = { list: [] }; // ... } // 或者使用 thunk 初始化在 Reducer 中调用外部 API 或全局变量： 绝对不要这样做。如果需要获取当前时间，请在 Action Creator 中获取，或者使用
Date.now()但要注意它不是纯的，最好由上层注入。忘记返回状态： 如果 Switch 语句中没有匹配的动作，且没有
default返回state，函数将隐式返回undefined，导致 Redux 报错。滥用
Object.assign或lodash.cloneDeep： 虽然cloneDeep能解决不可变性问题，但它性能较差，且会丢失原型链。推荐使用展开运算符或 Immer。
总结：从“信任”到“掌控”
Redux 要求 Reducer 是纯函数，不仅仅是为了遵循某种学术上的洁癖，而是为了在大规模应用中建立对数据的绝对信任。
当你不再担心某个组件偷偷修改了全局状态，不再担心异步操作打乱了状态更新的顺序，不再担心单元测试因为环境差异而失败时，你就真正掌握了状态管理的精髓。
记住，副作用是必要的，但它们应该被限制在特定的边界内（如 Middleware 或 Action Creators）。Reducer 的世界应该是安静、有序、可预测的。就像一位老练的厨师，切菜、调味、烹饪，每一步都井井有条，最终呈现出一道完美无瑕的菜肴。
希望这篇详解能帮你理清 Redux 中 Reducer 的核心逻辑。下次当你写下 return { ...state, ...newData } 时，不妨在心里默念一句：“我是纯的，我很安全。”