React Query 依赖查询

date

Nov 5, 2025

slug

react-query-dependency-query

status

Published

场景再现：导演在哪里？

想象你在做一个电影网站。API 设计师（可能是实习生）给你的接口是这样的：

这就像点外卖：

"给我来份套餐A"

"好的，这是你的取餐码：123"

"那我的餐呢？"

"拿着取餐码去窗口取..."

方案一：简单粗暴的"打包带走"

没有 React Query 时，我们会这么写：

用 React Query 实现？直接把这逻辑塞进 queryFn：

看起来不错？且慢！这就像把土豆和牛肉一起炖——虽然能吃，但有问题！

"打包方案"的三宗罪

1. 捆绑销售，不能单买

这就像买手机必须买充电器，买充电器又必须买手机壳... 都绑在一起了！

2. 一损俱损

这就像考试：一道题不会，整张卷子交白卷？

3. 重复劳动（最严重！）

假设《教父1》和《教父2》都是同一个导演：

同一个导演的信息，存了两份，请求了两次！这就像去同一家店，买了两次会员卡...

方案二：优雅的"分而治之"

更好的方法是把查询分开，但保持依赖关系：

工作流程图解

让我们看看这个优雅的链式反应：

独立查询的好处

1. 灵活配置

2. 智能去重

3. 优雅降级

实战技巧

处理多级依赖

并行 + 依赖混合

何时打包，何时分离？

打包（组合查询）适合：

数据紧密耦合，总是一起使用

不需要单独缓存控制

简单的父子关系

分离（依赖查询）适合：

数据可能被多处复用

需要不同的缓存策略

可以独立显示部分数据

存在去重机会

总结

依赖查询的精髓：

用 enabled 控制执行时机：没有依赖数据就不执行

保持查询独立：每个查询有自己的缓存键

享受自动去重：相同的查询自动共享缓存

优雅处理状态：每个查询有独立的加载/错误状态

记住：依赖查询就像接力赛，每一棒都要等前一棒到位才能开始。但与接力赛不同的是，React Query 会帮你自动管理这个"交接棒"的过程！

选择合适的方案，让你的数据获取既高效又优雅！