SWR 核心概念：过期即重新验证

SWR 是“过期后重新验证”的缩写，这是一种由 RFC 5861 定义的 HTTP 缓存策略。该策略会先立即向用户提供过期（缓存）数据，然后在后台重新验证，并在最新数据到达后更新界面。

这种方式优先考虑用户感知的性能：用户可以立即看到数据，而不必等待一次网络往返。

在传统的加载模式下，用户每次导航都会看到加载指示器。使用 SWR 时，用户会立即看到上次已知的数据；如果数据发生变化，界面会在后台静默更新。

这会让应用明显感觉更快，也能减少加载状态对用户认知造成的干扰。

SWR 会在以下情况下自动重新验证数据：浏览器窗口重新获得焦点（用户切换标签页后返回）、离线后网络连接恢复、显式调用 mutate()，或可配置的 refreshInterval 计时器触发。

这些自动触发条件可以保持数据新鲜，无需开发者手动管理重新获取逻辑。

一个 SWR 键可以处于以下几种状态之一：加载中（没有缓存数据，正在进行首次获取）、重新验证中（已有缓存数据，正在进行后台刷新）、错误（请求失败）或成功（有最新数据可用）。

理解这些状态有助于您构建准确的加载骨架屏和错误界面。

SWR 维护一个以请求键为索引的全局内存缓存（通常是一个 URL 字符串）。任何请求相同键的组件都会获得相同的缓存值，并参与同一个重新验证周期。

这种自动去重意味着，即使 10 个组件分别使用相同的键调用 useSWR，也只会发出一个网络请求。

SWR 将缓存管理逻辑与实际的数据获取过程分离。您需要提供一个 fetcher 函数：它是一个接受键并返回数据的异步函数。

fetcher 可以替换：您可以使用 fetch、axios、graphql-request 或任何异步数据源。无论 fetcher 如何工作，SWR 都会负责缓存和重新验证。

请使用包含 fetcher 函数的 value 属性将应用包裹在 SWRConfig 中：value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}。每个省略 fetcher 参数的 useSWR 调用都会使用这个全局默认值。

这样可以将 API 配置（基础 URL、身份验证标头）集中在一个位置，而不必在每次调用钩子时重复配置。

经典模式使用 useEffect + useState 手动管理加载、数据和错误状态。SWR 通过一次钩子调用取代了所有这些工作，并自动处理缓存、去重、后台刷新和错误重试。

代码量会显著减少：典型的数据获取组件可以从 20 多行缩减到 3 行。

缓存键用于唯一标识一个请求。对于简单情况，请使用 URL 字符串。对于带参数的请求，请使用数组键：[url, params]，其中 params 是稳定的对象或字符串。传入 null 会停用该请求。

良好的缓存键设计可以确保相关请求共享缓存条目，而不相关的请求不会发生冲突。

SWR 能够智能地进行重新验证：dedupingInterval（默认 2 秒）可以防止许多组件同时挂载时重复触发重新验证。在去重时间窗口内，每个键只会发出一个请求。

这可以避免大型组件树中常见的惊群问题，因为大型组件树中的许多组件可能会获取相同的数据。

SWR 由 Next.js 背后的公司 Vercel 开发，二者的集成非常顺畅。getServerSideProps 或 getStaticProps 可以预先获取数据，SWR 会在客户端使用该预取值完成水合。

这样既能获得服务器渲染的初始 HTML，又能在挂载时自动进行客户端重新验证，将 SSR 和 SWR 的优势结合起来。

以下哪项默认不会（NOT）触发 SWR 重新验证？

SWR 实现了“过期后重新验证”策略：立即提供缓存数据，在后台重新验证，并在数据更新后刷新界面。它会在获得焦点、重新连接、调用 mutate 以及轮询时触发重新验证。全局缓存会跨组件对请求进行去重，而 fetcher 函数可以完全替换。

这种模式大幅简化了数据获取代码，同时带来更快的用户感知性能。