你什么时候实际上需要状态管理库？

Question

你什么时候实际上需要状态管理库？

Accepted Answer

你**并不总是需要一个**。现代框架拥有强大的内置状态工具，过早使用Redux/Zustand会增加复杂性。诚实的答案是：只有当内置选项变得令人困扰时，才添加一个库。

## 从内置工具开始

```jsx
// most state needs are met by:
const [x, setX] = useState();           // local component state
const value = useContext(MyContext);    // share across a subtree
const memo = useMemo(() => derive(), [x]); // derived values
// + a server-state library (React Query) for fetched data
```

Local state + Context + (用于远程数据的) React Query 涵盖了绝大多数应用。许多生产应用根本不需要全局状态库。

## 表明你可能真正需要库的迹象

```text
✓ Lots of GLOBAL state shared across many distant components
✓ Complex state interactions / frequent updates that Context handles poorly
                       (Context re-renders all consumers on any change)
✓ You need devtools, time-travel debugging, or strict update traceability
✓ Many components both read AND write the same shared state
✓ Predictable, centralized update logic matters for a large team
```

## 为什么不干脆"总是使用Redux"？

```text
Cost of a library: boilerplate, learning curve, more indirection, bundle size.
For a small/medium app, that cost often outweighs the benefit.
```

## 让工具适应需求

```text
Server/remote data        → React Query / SWR (NOT a global store)
A few global values        → Context, or a tiny store (Zustand/Jotai)
Large, complex shared state→ Redux Toolkit, or Zustand for less boilerplate
Form state                 → a form library (React Hook Form), not global state
```

大量"我们需要Redux"的情况实际上是一个服务器状态问题，用React Query解决得更好，或者只是一些值用Context/Zustand解决。

## 为什么这很重要

了解**何时**需要状态库可以防止过度设计的常见错误——向只需要`useState`和Context的应用添加Redux。

成熟的做法是从简单开始，确定**具体的**痛点（深度共享、复杂更新、服务器缓存），然后为该痛点选择**正确的**工具（通常是轻量级存储或服务器状态库，而不是重型全局库）。

选择符合需要的最小化解决方案可以让应用更简洁、构建更快、维护更容易。