React Query 管理突变

date

Nov 5, 2025

slug

react-query-managing-mutations

status

Published

开篇：读和写的本质区别

先看看 React 的 useState：

客户端状态更新很简单——你说了算，立即生效。

但服务器状态呢？

为什么不能用 useQuery 做更新？

你可能会想：

问题大了：

组件一挂载就执行：用户还没点按钮呢！

会自动重复执行：窗口获得焦点就重新更新？

不是幂等的：查询执行100次结果一样，更新执行100次... 💀

这就像：

查询 = 看菜单（看100次也没事）

更新 = 点菜（点100次要破产）

useMutation：专门处理更新的钩子

useMutation 就是为更新而生的：

关键区别：

useQuery：自动执行

useMutation：手动触发

生命周期管理：不只是发请求

useMutation 真正的价值在于管理更新的生命周期：

状态流转：

idle：待命中

pending：执行中

success：成功了

error：失败了

生命周期钩子：在关键时刻做事

方式一：在 mutate 时传入

方式二：在 useMutation 中配置

突变与查询的协作：更新缓存

更新成功后，如何让 UI 立即显示新数据？

方案一：手动更新缓存

这就像：改了名字后，直接在身份证上涂改（快但危险）。

如果 API 不返回完整数据？

⚠️ 重要：必须返回新对象！

复杂场景：多个缓存条目

想象一个待办事项应用，有不同的排序方式：

添加新待办事项后，要更新所有列表？

笨方法：逐个更新

问题：

代码重复

容易出错

客户端排序逻辑可能与服务器不一致

聪明方法：缓存失效

这就像：改了菜单后，让所有人重新拿一份（准确但稍慢）。

模糊匹配：一石多鸟

invalidateQueries 的强大之处在于模糊匹配：

查询键的层次结构

从通用到具体：

这就像文件系统：

高级失效技巧

只失效过期的查询

只失效活跃的查询

自定义过滤

最佳实践对比

方案	适用场景	优点	缺点
手动更新	单个缓存条目	即时生效	逻辑复杂
缓存失效	多个缓存条目	数据准确	需要重新请求
混合方案	关键数据	平衡速度和准确性	代码较多

混合方案示例

TypeScript 小贴士

总结

useMutation 让数据更新变得优雅：

生命周期管理：从 pending 到 success/error

手动触发：完全控制何时更新

缓存同步：

简单场景：手动更新

复杂场景：缓存失效

模糊匹配：一次失效多个查询

层次化键：组织良好的缓存结构

记住：

查询 = 看菜单（随便看）

突变 = 改菜单（谨慎改）

缓存失效 = 重新打印菜单（确保最新）

选择合适的策略，让你的数据更新既快速又准确！