如此使用React Query的useQuery是否属于反模式？

代码示例 #

首先是用于初始化缓存的useFoo钩子：

export const useFoo = () =>
  useQuery(['example-key'], (): Nullable<Foo> => null);

然后是用于更新状态的useUpdateFoo钩子：

export const useUpdateFoo = () => {
  const queryClient = useQueryClient();

  return useMutation(
    ['example-useMutation_key'],
    async () => {
      // 假设此处API调用返回正确数据
    },
    {
      onSuccess: (response) => {
        queryClient.setQueryData(['example-key'],() => response);
      },
    }
  );
};

疑问 #

这种useQuery不执行FETCH操作的用法是否属于反模式？同事认为若useQuery不执行FETCH操作就不应使用它。若不是反模式，该方式存在哪些局限？

回答 #

这种写法不算严格的反模式，但属于React Query的非典型用法——毕竟React Query的核心定位是管理服务端异步状态的工具，默认逻辑围绕"发起请求获取数据"设计。不过它确实能运行，本质是把React Query当作轻量全局缓存来用。

但这种用法存在不少局限：

• 浪费内置能力：React Query的自动重试、背景刷新、stale-while-revalidate等特性都是为请求场景设计的，无请求写法完全用不上这些功能，相当于只使用了缓存和状态管理的子集，有点大材小用。
• 语义混淆：团队协作时，其他开发者看到useQuery会默认认为这是服务端数据查询逻辑，无请求的写法会增加理解成本，容易造成误解。
• 维护性差：如果后续业务需要从服务端加载初始数据，这种写法需要大幅重构；相比之下，一开始用标准useQuery（比如用enabled控制是否发起请求）或者专门的状态管理工具（如Zustand、Context）会更灵活。
• 缓存策略冲突：React Query的缓存过期、垃圾回收机制是为请求场景优化的，用来存储本地更新的状态可能出现意外的缓存清理——比如长时间不触发useQuery的组件挂载，缓存条目可能被自动回收。

总结：如果是临时存一个简单状态，这种写法可以凑合用；但如果是长期维护的业务逻辑，更推荐用专门的状态管理工具，或者调整为标准的React Query查询模式。

内容的提问来源于stack exchange，提问作者sonphung.xf