根据状态的类型匹配工具,而不是默认地使用全局存储。大多数"全局状态"问题实际上是用错了工具。
为什么这很重要
text
Local UI state (toggle, input) → useState / useReducer
Shared, low-frequency (theme, user) → Context
Server/API data → React Query / SWR (NOT a global store)
Complex global client state → Zustand / Jotai / Redux Toolkit
URL-shareable state (filters, page) → the URL (search params)
最重要的洞察:server state ≠ client state
来自 API 的数据是远程数据的缓存,不是你拥有的状态。将其放在 Redux 中意味着你必须手动处理加载、缓存、重新获取和失效——痛苦且容易出错。Server-state 库能做到这一切:
jsx
// handles caching, dedup, background refetch, stale-while-revalidate for free
const { data, isLoading } = useQuery({ queryKey: ["todos"], queryFn: getTodos });
指导原则
- 尽可能保持状态局部;将其与使用位置并置。
- 不要在 Context 中放入快速变化的值(它会重新渲染所有消费者)。
- 对于频繁更新的共享客户端状态,倾向于使用具有选择性订阅的存储(Zustand/Jotai),以便组件仅对其读取的切片重新渲染。
- 当需要在真正复杂的共享状态上使用 Redux Toolkit 的 devtools/middleware/structure 时才使用它。
真正的技能是最小化和正确放置状态——而不是选择库。
