状态管理库越用越乱？把服务端状态和客户端状态分开管

2024 年我们的项目用了 Redux，所有状态往一个 store 里塞。用户信息、主题配置、弹窗开关、表单草稿、API 缓存，全混在一起。后来加了 React Query，发现它也在管缓存，两个系统互相覆盖，调试时不知道数据到底从哪来。

问题的根源是把两种完全不同的状态当成一种东西在管。

服务端状态是别人给你的。用户列表、订单详情、商品库存，这些数据存在数据库里，你的应用只是临时借用。它们会过期、会被别人修改、需要重新获取。特性是：异步、不可控、有生命周期。

客户端状态是你自己生的。当前选中的标签页、表单输入值、侧边栏展开状态、主题颜色。这些数据只存在于当前会话，刷新页面就消失。特性是：同步、可控、临时性。

Redux 和 Zustand 这类通用状态管理库，设计之初没有区分这两者。它们假设所有状态都是"你的"，可以随便改。但服务端状态不是"你的"，你只是"租"来的，租期到了要续租，房东卖了你要跟着变。

解决办法是双轨制，井水不犯河水。

服务端状态交给专门的数据获取库。TanStack Query 或者 SWR，它们帮你处理缓存、失效、重试、竞态、背景更新。你不需要写 reducer，不需要写 action，声明 key 和 fetcher 就行。

jsx
复制
// 服务端状态：交给 React Query
const { data: user } = useQuery({
  queryKey: ['user', id],
  queryFn: () => fetchUser(id)
});

// 客户端状态：交给 Zustand 或 useState
const sidebarOpen = useUIStore(state => state.sidebarOpen);

客户端状态用轻量库。Zustand、Jotai、甚至原生 useState，根据作用域大小选。全局的用 Zustand，局部的用 useState，跨组件但不跨页面的用 Context。

关键边界怎么划？

如果这个数据来自 API，就是服务端状态。即使你现在把它存在 Redux 里，也建议迁出来。Redux 里存 API 数据是 2018 年的做法，2026 年已经有更好的工具。

如果这个数据刷新页面后应该保留，考虑服务端持久化或者 localStorage，而不是往状态管理库里塞。状态管理库是内存里的，页面关了就没。

如果这个数据是"派生"的，比如从用户列表过滤出 VIP 用户，不要新建状态，用 useMemo 计算。派生状态是 bug 的重灾区，源头一变，派生忘了更新。

我的观点：

状态管理乱，不是因为库不好，是因为分类不清。2026 年的最佳实践是服务端状态和客户端状态分治，各自用最合适的工具。不要一个 Redux 管所有，也不要为了"统一"而强行合并。工具是手段，清晰的数据边界才是目的。

你的项目里服务端状态和客户端状态混在一起吗？有没有因为状态来源不清出过 bug？

原创

0 cool

暂无评论，来说两句吧

登录后评论