SWR 与 React Query：选择合适的工具

SWR 经 gzip 压缩后约为 7kb。React Query v5 经 gzip 压缩后约为 13kb。体积差异反映了 React Query 的额外功能：查询预取、查询取消、更详细的查询生命周期以及内置 DevTools。

对于注重体积的应用，或采用简单获取并显示模式的应用，SWR 更小的体积是一项显著优势。

SWR 的 API 更简单、更精简。如果您的主要需求是获取数据并在自动重新验证的同时显示数据，SWR 只需极少的样板代码就能优雅地满足这一需求。

SWR 由 Vercel 构建，因此与 Next.js 的集成非常出色，尤其适合将 getServerSideProps 或 getStaticProps 的预取与客户端通过回退数据进行的重新验证结合起来。

请通过 SWRConfig 中的 fallback 选项或 useSWR 中的 fallbackData 选项，将预取的数据传给 SWR。SWR 会将其作为初始缓存值，从而消除首次加载时的闪烁，同时启用后台重新验证。

对于使用 Vercel 的 Next.js Pages Router 应用，这是推荐的数据获取方式。

React Query 可以更精细地控制查询生命周期：staleTime、gcTime（垃圾回收）、refetchOnWindowFocus、重试次数和重试延迟都可以分别配置。其带有 onSuccess、onError 和 onSettled 回调的变更系统表达力很强。

React Query 还支持通过 AbortSignal 取消查询，这对于边输入边搜索的用户界面非常有用。

React Query 的 useInfiniteQuery 与 getNextPageParam 专门用于无限滚动和加载更多模式。它会管理页面游标逻辑，并提供扁平或结构化的 pages 对象。

SWR 的 useSWRInfinite 也能覆盖类似场景，但 API 层级略低，需要手动组装更多页面。

React Query 支持在悬停或路由变更时通过 queryClient.prefetchQuery 预取查询数据。组件挂载前数据就已在缓存中，因此能够立即渲染。

除了 SSR 回退数据之外，SWR 没有内置的预取 API。对于基于悬停的预取，React Query 是更好的选择。

React Query v5 简化了 API：useQuery 返回 isPending 而不是 isLoading，统一了乐观更新模式，并改进了 TypeScript 类型推断。与早期版本相比，v5 API 更简洁、更一致。

如果您正在评估 React Query，请直接选择 v5，而不要先学习 v4 再进行迁移。

SWR 会按键在各个组件之间全局共享缓存条目，除了使用 SWRConfig 设置默认值外，无需任何提供者配置。React Query 则需要使用带有 QueryClient 实例的 QueryClientProvider。

对于快速原型开发或简单应用，SWR 的零配置全局缓存设置起来更快。对于缓存需求复杂的大型应用，React Query 的显式客户端更合适。

当您的应用主要构建于 Next.js 之上、数据获取模式较为直接（fetch-display-revalidate）、您希望减小打包体积，或团队更重视 API 的简洁性而非高级功能时，请选择 SWR。

如果要将增量式数据获取库引入现有代码库，而又不想进行大规模迁移，SWR 也是很好的选择。

当您需要复杂的服务端状态管理时，请选择 React Query，例如无限滚动、查询预取、后台重新获取策略、多步骤查询依赖，或对缓存 TTL 进行精细控制。

React Query 还拥有更活跃的中间件和 DevTools 生态，其 queryClient 也更容易单独进行测试。

有些团队会同时使用两者：在叶子组件中使用 SWR 获取简单的单个资源，在带有预取功能的复杂多查询页面中使用 React Query。虽然这种做法并不常见，但如果团队熟悉两套 API，也是可行的。

更常见的做法是选择其中一个，并在整个应用中保持一致，以避免上下文切换和双重依赖开销。

SWR 和 React Query 的打包体积大致有什么区别？

SWR（约 7kb）更简单，并且能原生集成 Next.js，使用极少的代码就能覆盖大多数获取并显示数据的模式。React Query（约 13kb）提供了更丰富的功能：无限查询、预取、精细的生命周期回调以及查询取消。

对于注重简洁性和 Next.js 的项目，请选择 SWR；对于复杂的服务端状态需求，请选择 React Query。两者都支持 TypeScript、Suspense、SSR 和离线模式。