先问：真的需要状态库吗#

我见过太多项目一上来 npm i redux，结果 90% 的状态都是局部 useState 能解决的。状态管理的代价是额外的抽象和心智负担，别为”可能以后要”提前引入。

分层决策：

useReducer：复杂本地状态#

当 state 有多个子值、多种变更动作时，useReducer 比一堆 useState 清晰：

1
function reducer(state, action) {
2
  switch (action.type) {
3
    case "add": return { ...state, items: [...state.items, action.item] };
4
    case "remove": return { ...state, items: state.items.filter(i => i.id !== action.id) };
5
    default: return state;
6
  }
7
}
8
const [state, dispatch] = useReducer(reducer, { items: [] });
9
dispatch({ type: "add", item });

轻量全局：Zustand#

1
import { create } from "zustand";
2
const useStore = create(set => ({
3
  user: null,
4
  setUser: (u) => set({ user: u }),
5
}));
6
// 组件内
7
const user = useStore(s => s.user);

比 Redux 少一堆样板，按需订阅、无 Provider 包裹，中小型项目首选。

Redux 何时值得#

需要时间旅行调试、严格可预测、中间件生态（如 redux-saga 处理复杂异步）的大型应用才上。现代 Redux 用 @reduxjs/toolkit 已大幅减负，但样板仍多于 Zustand。

小结#

• 默认 useState；跨层 useContext；复杂本地 useReducer；真全局才上库。
• Zustand 是轻量全局状态首选；Redux 留给需要强约束的大型应用。
• 别提前引入状态库——它带来的是复杂度，不是免费午餐。

练习#

1. 把一个”多字段表单 + 多个 action”的 useState 堆砌改写成 useReducer。
2. 用 Zustand 建一个 cart store，实现添加/删除/计数。
3. 画一张决策图：什么时候用 useState / context / 状态库。