Solid Query 能否取代 Redux、MobX 或 Zustand？剖析 Server State 与 Client State 的边界

本指南围绕 TanStack Query 生态中一个高频提问展开：在 SolidJS 应用中，Solid Query 到底要不要替代 Redux、MobX、Zustand 等全局状态管理器？答案并非简单的"是"或"否"，而是取决于状态的性质——是源自服务器的异步数据，还是纯客户端的同步状态。读完本文，你将掌握两者的划分标准、Solid Query 实际替换的样板代码范围，以及哪些场景下应当继续保留客户端状态管理器、如何与 Solid Query 协同共存。

本文内容源自仓库中的官方指南 docs/framework/solid/guides/does-this-replace-client-state.md。该文件通过 frontmatter 中的 ref 字段引用同主题的 React 版主源文档，并以 replace: { 'hook': 'function' } 规则做术语替换后生成，因此两版指南的结论与结构完全一致，只是表述上贴合 Solid 的函数式 API 风格。

结论先行：TanStack Query 不是"另一个状态库"，而是 Server-State 库

要回答"是否取代"，先要厘清一个最容易混淆的前提。原指南开篇给出了两条关键定义：

• TanStack Query（Solid 生态中即 @tanstack/solid-query）是一个 Server-State（服务端状态）库，职责是管理服务器与客户端之间的异步操作——请求的发起、缓存、重试、失效、窗口聚焦重取等；
• Redux、MobX、Zustand 等是 Client-State（客户端状态）库，它们理论上也可以用来存放异步数据，但与 TanStack Query 这类专为服务端状态设计的工具相比，效率低下。

基于这两点，原指南给出简短答案：

TanStack Query 取代的是你为了在客户端状态库里管理缓存数据而编写的那一整套样板代码和相关接线（wiring），并把它们替换成寥寥几行代码。

换言之，它取代的对象不是"状态管理器"这个软件本身，而是"用状态管理器去手工维护服务端缓存"这件事——Action、Reducer、中间件、Loading/Error 标志位这些围绕异步数据的手工管道，才是真正被替代的部分。

一个对照实验：迁移前后，你的 Global State 还剩多少

为了直观说明这种替代关系，原指南提供了一个假设示例。假如你的全局 store 目前长这样：

const globalState = {
  projects,
  teams,
  tasks,
  users,
  themeMode,
  sidebarStatus,
}

可以观察到，这个"全局状态"里其实混装着两类截然不同的东西：

• projects、teams、tasks、users——4 种服务端状态，本质是服务器数据的本地缓存；
• themeMode、sidebarStatus——2 种纯客户端状态，只与 UI 交互相关，服务器不参与。

如果把这 4 份服务端数据迁到 TanStack Query 管理，剩余的全局状态就会变成：

const globalState = {
  themeMode,
  sidebarStatus,
}

这正是该主题的核心直觉：对于绝大多数应用而言，把所有异步代码迁到 TanStack Query 之后，真正剩下的"全局可访问的客户端状态"通常非常小。 与其把项目列表、用户信息这类高频变化、强一致性的服务端数据塞进全局 store，不如让它们住在 query cache 里，由 Solid Query 统一负责生命周期。

被替换掉的具体样板代码清单

把服务端状态迁移到 Solid Query 后，随之而来的收益是：原本为管理服务端数据而写的大量 boilerplate 可以整体删除。原指南列出了这些可以移除的部分：

• Connectors（连接器/桥接层）：把 store 与组件连接起来的样板代码；
• Action Creators（动作创建器）：描述"数据变更意图"的分发对象；
• Middlewares（中间件）：拦截、日志、副作用编排等异步管道；
• Reducers（归约器）：根据 action 生成新状态的纯函数；
• Loading / Error / Result 状态（异步三态样板）：遍布各处的 isFetching、error、hasLoaded 等标志位及其手写逻辑；
• Contexts（上下文）：为了跨组件共享异步数据而手动搭建的 Provider/Context 链条。

在 SolidJS 中，这些手工状态管理组件中的相当一部分，恰好对应了 packages/solid-query/src/index.ts 里暴露的能力：useQuery/useMutation/useInfiniteQuery 返回的响应式结果天然携带 isPending、isError、isSuccess、data、error 等状态，开发者无需再自行维护"请求中/失败/成功"三态；QueryClient 与 QueryClientProvider 取代手写的 Context 传递，缓存、重试、失效机制则由其底层 @tanstack/query-core 统一承担。

用指南中的话总结：这些样板代码被移除后，问题就变成——"为了这仅剩的一点全局状态，还值得继续保留客户端状态管理器吗？"而答案取决于你自己。 但 Solid Query 的职责边界是清晰的：它把应用里的异步接线和样板，替换成寥寥数行代码。

边界情形：哪些应用仍然应该保留客户端状态管理器

原指南同时强调了一个重要的例外，切不可把"取代样板代码"误读成"取代一切状态库"：

确实存在某些应用含有海量的同步纯客户端状态——比如可视化设计器（visual designer）或音乐制作类应用。这种情况下，你很可能仍然需要客户端状态管理器。值得注意的是，TanStack Query 不是本地/客户端状态管理的替代品。不过，你可以毫无障碍地将 TanStack Query 与大多数客户端状态管理器搭配使用。

这条边界可以帮助你做出务实的架构判断：

状态类型	典型例子	推荐归属
服务端状态	项目列表、团队/任务/用户数据、任何来自 API 的缓存	Solid Query（query cache）
少量全局 UI 状态	主题模式、侧边栏开合	原生状态、Context 或轻量 store 均可
海量同步客户端状态	设计画布、音频编排、富文本编辑器内部模型	客户端状态管理器仍是最优解

当第三种场景出现时，并不需要二选一。Solid Query 与 Redux/MobX/Zustand 等可以零问题共存：异步数据交给 Solid Query，纯客户端状态继续留在 store。仓库中 docs/framework/solid/guides/caching.md 等指南也印证了这种"各自归位"的分工思路。

源码支撑：从实现看 Solid Query 的 API 形态与数据流

为了让上述结论更有依据，可以看几处 Solid Query 的真实实现。

其一，API 命名与别名机制。 在 packages/solid-query/src/index.ts 中可以看到，createQuery = useQuery、createMutation = useMutation、createInfiniteQuery = useInfiniteQuery 等，源码注释明确写道 "Aliases (create* and use* are both supported)"，即两种前缀均可使用，use 前缀是当前指南文档采用的表述。

其二，响应式接入方式。 与 React 版不同，Solid 版的 useQuery 接收的是选项函数并借助 createMemo 包装后传给基础实现，见 packages/solid-query/src/useQuery.ts：

export function useQuery(options, queryClient?) {
  return useBaseQuery(
    createMemo(() => options()),
    QueryObserver,
    queryClient,
  )
}

这正对应官方指南 docs/framework/solid/guides/queries.md 中的调用形态：

import { useQuery } from '@tanstack/solid-query'

function App() {
  const todosQuery = useQuery(() => ({
    queryKey: ['todos'],
    queryFn: fetchTodoList,
  }))
}

其三，变更操作基于 MutationObserver。 packages/solid-query/src/useMutation.ts 中通过 new MutationObserver 建立观察者，并借助 createComputed/createMemo/onCleanup 将观察结果接入 Solid 的响应式系统，返回的 mutation.isPending、mutation.mutate 等即为指南 docs/framework/solid/guides/mutations.md 中演示的用法。

从这些实现可以看到，所谓"用几行代码取代整套异步样板"并非宣传话术——isPending/isError/isSuccess/data/error 这组原本需要手写在 store 里的状态机，全部内建在 observer 的返回结构中，组件只负责消费响应式结果即可。

落地建议：如何逐步把异步状态从全局 Store 中迁出

如果你认同上述边界，可以按以下顺序在 SolidJS 工程中完成迁移，而不必一次性推翻现有状态方案：

1. 安装并搭建基础结构。 参考 docs/framework/solid/quick-start.md，安装 @tanstack/solid-query，创建 QueryClient 并用 QueryClientProvider 包住组件树，替代原先用于异步数据的 Context/Store 接线。
2. 逐个替换读路径。 对于 store 中每个来自 API 的集合（如上面的 projects、users），用 useQuery(() => ({ queryKey: [...], queryFn: ... })) 替代从 store 读取 + 手动触发拉取的逻辑。返回的 query 对象是响应式信号，可直接在 Switch/Match 或 <For> 中消费。
3. 逐个替换写路径。 创建/更新/删除类操作由 useMutation 接管，配合 queryClient.invalidateQueries() 实现变更后的缓存刷新，替换原先 dispatch action → middleware → reducer 的链路。
4. 验证存量 store 的剩余内容。 迁移完成后，重新审视全局 store——它现在是否只剩 themeMode、sidebarStatus 这类纯 UI 状态？如果答案是肯定的，就可以权衡是否还有必要为它保留一套完整的状态管理库，还是改用更轻量的方案。

在迁移过程中，Solid Query 的 server-state 缓存具备多数状态库难以原生覆盖的能力：查询去重、后台重取、失效与乐观更新等，相关机制可继续阅读 docs/framework/solid/guides/caching.md、docs/framework/solid/guides/query-invalidation.md 与 docs/framework/solid/guides/optimistic-updates.md 深入掌握。

小结

回到本文标题的问题：Solid Query 是否取代全局状态管理器？

• 它取代的是异步/服务端状态管理样板：用 useQuery/useMutation 寥寥几行代码，替代 Connectors、Action Creators、Middlewares、Reducers、异步三态与 Contexts；
• 它不取代客户端状态管理本身：迁移后绝大多数应用剩余的全局纯客户端状态极小，但像可视化设计器、音乐制作这类存在海量同步状态的场景，仍需客户端状态管理器；
• 两者完全可以共存：把服务器数据留在 query cache，把 UI 偏好留在 store，各司其职，互不干扰。

最核心的工程判断其实只有一句：先分清你的状态来自服务器还是来自界面，再决定它应该住在哪里。