前端向架构突围系列 - 状态数据设计 [8 - 3]：服务端状态与客户端状态的架构分离

写在前面

架构师的核心能力之一是分类。如果你觉得状态管理很痛苦，通常是因为你试图用同一种工具处理两种截然不同的东西：

客户端状态 (Client State): 比如"侧边栏是否展开"、"当前的夜间模式"。它们是同步的、瞬间完成的、由前端完全控制。

服务端状态 (Server State): 比如"用户订单列表"。它们是异步的、可能失效的、由后端控制。

Redux 并不擅长管理 Server State。 真正专业的做法是：让 Redux 回归 UI，让 TanStack Query (React Query) 接管 API。

一、为什么要把 API 赶出 Redux？

1.1 消失的"样板代码"

在传统的 Redux 处理 API 流程中，你需要写：

一个 Constant 定义 FETCH_USER_REQUEST
一个 Action Creator
一个处理 Pending/Success/Error 的 Reducer
一个 useEffect 来触发请求

而在 TanStack Query 中，这只需要一行代码：

php 复制代码

const { data, isLoading } = useQuery({ queryKey: ['user'], queryFn: fetchUser });

1.2 缓存与失效：Redux 的盲区

Server State 最难的不是"获取"，而是**"维护"**。

用户离开页面 5 分钟后回来，数据还是新的吗？
两个组件同时请求同一个接口，会发两次请求吗？
弱网环境下，请求失败了会自动重试吗？如果要用 Redux 实现这些，你需要写几百行复杂的 Middleware。而这些，是 Server State 管理工具的标配。

二、架构模型：双层数据流

现代前端架构推荐采用 "双层分离" 模型：

2.1 外部层：服务端状态 (Server State)

工具： TanStack Query (React Query) 或 SWR。
职责： 缓存管理、自动预取、失效检查 (Stale-While-Revalidate)、请求去重。
特点： 它是异步的。

2.2 内部层：客户端状态 (Client State)

工具： Zustand, Pinia, Jotai 或简单的 React Context。
职责： 管理纯粹的 UI 逻辑（开关、多语言、主题、临时草稿）。
特点： 它是同步的。

三、实战战术：从"手动挡"切换到"自动挡"

3.1 自动化的依赖追踪

想象一个场景：你修改了用户的头像，你需要更新所有显示头像的地方。

旧模式 (Redux): 修改成功后，手动发起一个 updateUserAction 去修改 Redux 里的那个大对象。
新模式 (Query): 只需要执行一次"失效（Invalidate）"。

php 复制代码

// 当用户修改个人资料成功时
const mutation = useMutation({
  mutationFn: updateProfile,
  onSuccess: () => {
    // 告诉系统：['user'] 这个 key 下的数据脏了，请自动重新拉取
    queryClient.invalidateQueries({ queryKey: ['user'] })
  },
})

架构意义： 你的代码不再需要关心"数据怎么同步"，只需要关心"数据何时失效"。

3.2 乐观更新 (Optimistic Updates)

这是架构高级感的核心。当用户点赞时，我们不等后端返回，直接改 UI。

TanStack Query 允许你在 onMutate 中手动修改缓存副本，如果请求失败，它会自动回滚。这种复杂的逻辑如果写在 Redux 里，会让 Reducer 逻辑变得极度臃肿。

四、选型决策：什么时候该用谁？

作为架构师，你需要给团队划清界限：

状态类型	典型例子	推荐工具	存储位置
API 数据	商品列表、用户信息	TanStack Query	专用 Cache 池
全局 UI 状态	登录 Token、全局主题	Zustand / Pinia	全局 Store
局部 UI 状态	某个弹窗的开关	useState	组件内部
复杂表单	多步骤注册表单	React Hook Form	专用 Form State

导出到 Google 表格

五、总结：让 Redux 变"瘦"

通过把 API 逻辑剥离出去，你会发现你的 Redux（或者 Zustand）Store 瞬间缩水了 80% 。剩下的代码变得极其纯粹：只有纯同步的 UI 逻辑。

这种**"分治"**带来的好处是巨大的：

心智负担降低： 你不再需要管理复杂的 loading 状态机。
性能提升： TanStack Query 的细粒度缓存比 Redux 的全量对比快得多。
开发效率： 团队成员可以更专注地编写业务逻辑，而不是在样板代码中挣扎。

结语：控制的艺术

我们已经成功地将 API 数据和 UI 状态分开了。但还有一种状态最让架构师头疼：流程状态 。当你的业务逻辑包含"待支付 -> 支付中 -> 支付成功/失败 -> 申请退款 -> 已关闭"这种复杂的链路时，无论你用什么工具，代码里都会充满 if/else。

这种逻辑该如何优雅地管理？

Next Step: 下一节，我们将引入一个在航天和游戏领域应用了几十年的数学模型。我们将学习如何用"图"的思想，终结代码里的逻辑乱麻。