SWR是Vercel推出的React Hooks数据请求库，名称来自HTTP缓存策略stale-while-revalidate。它的核心思路是：先返回缓存中的数据（stale），同时在后台发起重新验证请求（revalidate），最后用最新数据更新界面。这种模式让页面在二次访问时几乎瞬间呈现内容，用户感知延迟极低，而且天然适合处理多组件共享同一数据源的场景。

在传统的数据请求方案中，开发者需要手动管理请求状态、缓存、失效、去重和并发。SWR把这些通用逻辑封装进一个简单的Hook里，调用 useSWR(key, fetcher) 就能获得 data、error、isLoading 等状态。但仅仅会用还不够，理解内部原理才能写出更可靠的代码。

SWR的整体工作流程与缓存机制

SWR把数据请求抽象为三个参与者：缓存、fetcher和组件。缓存是一个全局的Map，键通常是请求的唯一标识字符串（例如API路径加查询参数），值包含数据、错误、时间戳、正在进行的请求Promise等元信息。当组件挂载时，useSWR会根据key去缓存Map中查找。如果存在缓存数据，立即返回该数据，同时判断是否需要重新验证。如果不存在缓存数据，则直接调用fetcher发起请求，请求期间返回undefined（或自定义的fallbackData）。

重新验证的时机由多个选项控制。默认情况下，以下几种事件会触发revalidate：组件挂载、窗口重新获得焦点、网络从断线恢复、以及开发者手动调用mutate函数。SWR通过监听浏览器的focus和online事件来实现自动刷新，这背后依赖一个全局的事件订阅中心。当任一触发条件满足时，SWR会发起新的请求，但不会丢弃旧数据，而是在后台更新。请求完成后，所有使用相同key的组件都会收到新的数据并重新渲染。

这种设计解决了两个常见问题：第一，多个组件复用同一个请求时不会产生重复的网络调用；第二，页面在用户切换窗口回来时能自动拿到最新数据，而用户看不到任何加载动画。SWR内部通过一个共享的缓存对象和订阅者列表来实现：每个使用相同key的组件都会注册一个更新回调，当缓存值变化时，所有回调依次执行。这种发布-订阅模式让数据能在组件间无缝同步。

源码核心解析：useSWR内部实现要点

打开SWR的源码（以版本2.x为例），核心逻辑集中在useSWR这个Hook里。它首先对key进行规范化处理：如果key是一个函数，则执行该函数获取实际key；如果key为数组（例如包含多个参数的请求），SWR会将数组序列化为一个稳定的字符串，通常使用serialize函数将数组元素用特殊分隔符连接。这样做的目的是保证key是基本类型，便于作为Map的键。

接下来，useSWR会检查全局缓存中是否存在当前key对应的缓存项。这个全局缓存通过一个模块级变量维护，所有组件共享同一个实例。如果缓存项不存在，SWR会创建一个初始状态对象，包含data设为undefined、error设为undefined、isLoading设为true等字段，并立即开始请求。如果缓存项存在，SWR会根据配置的revalidateOnMount、revalidateOnFocus等选项决定是否触发后台更新。这里有一个重要的细节：SWR不会在每次调用useSWR时都新建请求，而是复用缓存中已有的进行中的Promise，从而避免重复请求。

请求的实际执行由fetcher完成。fetcher是一个接收key作为参数的异步函数，必须返回一个Promise。SWR不关心fetcher内部使用axios、fetch还是其他库，只要返回Promise即可。请求发起后，SWR将其包装成一个带有状态跟踪的对象，比如记录开始时间、完成状态、错误信息。当Promise resolve时，SWR更新缓存中的data和isLoading，并触发所有订阅者的更新。如果Promise reject，则设置error并触发重新渲染。SWR还支持错误重试机制，默认在请求失败后间隔一定时间自动重试，这由errorRetryCount和errorRetryInterval选项控制。

除了数据请求，SWR还处理了组件卸载时的资源清理。当组件卸载后，它会从订阅者列表中移除当前组件的回调，避免内存泄漏。如果缓存中的数据是远程数据，并且设置了keepPreviousData或dedupingInterval，SWR还会在合适的时机清理超过有效期的缓存项。这些细节保证了长期运行的应用不会因为缓存无限增长而消耗过多内存。

// 简化的useSWR内部逻辑示意（非真实源码，仅用于理解）
const cache = new Map(); // 全局缓存
const subscribers = new Map(); // key -> Set<callback>
function useSWR(key, fetcher, options = {}) {
  const [state, setState] = useState(() => {
    const cached = cache.get(key);
    if (cached) {
      return { data: cached.data, error: cached.error, isLoading: false };
    }
    return { data: undefined, error: undefined, isLoading: true };
  });
  useEffect(() => {
    // 订阅该key的更新
    if (!subscribers.has(key)) {
      subscribers.set(key, new Set());
    }
    const callbacks = subscribers.get(key);
    const update = (newState) => setState(newState);
    callbacks.add(update);
    // 决定是否发起或复用请求
    let cached = cache.get(key);
    if (!cached) {
      cached = { data: undefined, error: undefined, promise: null };
      cache.set(key, cached);
    }
    if (!cached.promise || options.revalidateOnMount) {
      cached.promise = fetchData(key, fetcher, options);
    }
    return () => {
      callbacks.delete(update);
    };
  }, [key, fetcher, options]);
  return {
    data: state.data,
    error: state.error,
    isLoading: state.isLoading,
  };
}
async function fetchData(key, fetcher, options) {
  try {
    const data = await fetcher(key);
    const cached = cache.get(key);
    cached.data = data;
    cached.error = undefined;
    cached.promise = null;
    notifySubscribers(key, { data, error: undefined, isLoading: false });
    return data;
  } catch (err) {
    const cached = cache.get(key);
    cached.error = err;
    cached.promise = null;
    notifySubscribers(key, { data: cached.data, error: err, isLoading: false });
    throw err;
  }
}

常见问题与注意事项

第一个常见问题是条件请求。如果希望满足某个条件时才发起请求，很多开发者会这么写：useSWR(condition ? '/api/data' : null, fetcher)。SWR源码中确实做了特殊处理：当key为null或者为false时，它不会调用fetcher，并且返回的data保持undefined，isLoading为false。但是要注意，如果key从null变为实际字符串，组件会重新执行Hook并正常请求，这一点符合直觉。然而，如果fetcher函数本身在依赖数组中经常变化（例如每次渲染都重建的函数），SWR会因为fetcher引用变化而重新触发请求。此时需要用useCallback包裹fetcher，或者把fetcher移到组件外定义。

第二个容易踩坑的地方是依赖数组变化导致的数据不同步。SWR的key需要是稳定且能唯一标识数据的字符串。如果使用数组作为key，例如 useSWR([url, page, sort], fetcher)，SWR每次渲染都会将数组序列化为新的字符串，如果数组中的元素顺序或内容变了，就会产生新的key，导致缓存失效并重新请求。这是期望的行为，但问题在于序列化过程可能比想象中更敏感。例如对象字面量作为数组元素时，每次渲染都会生成新的引用，导致key不稳定。解决方法是把对象序列化为字符串，或者使用稳定的原始值组合。

第三个问题是全局缓存与组件状态的手动同步。SWR提供了mutate函数来手动修改缓存。调用mutate(key, newData)会立即更新缓存并通知所有订阅者，但不会自动发起重新验证。很多开发者在表单提交后使用mutate来乐观更新UI，却忘记随后调用mutate(key)（不带第二个参数）来触发后台重新验证。正确做法是：先乐观更新本地缓存，然后触发一次重新验证，让服务器数据最终成为权威来源。

第四个问题是服务端渲染（SSR）中的使用。SWR在服务端没有浏览器事件，也不会在服务端执行fetch（除非手动调用fetcher）。在Next.js等框架中，需要配合fallback或fallbackData来预填充缓存，否则客户端首次渲染会出现白屏或加载态。SWR提供了SWRConfig组件的fallback属性，可以把服务端获取的数据注入全局缓存，客户端挂载时直接使用这些数据，避免了额外的请求。

最后一点是性能与内存管理。SWR默认会缓存所有请求过的数据，而且不会主动清理。对于数据量很大的应用，长时间运行后缓存可能占用较多内存。可以通过设置dedupingInterval（去重时间间隔）来限制重复请求的频率，但缓存本身不会自动过期。如果需要清理，可以手动调用cache.delete(key)，或者在全局配置中使用provider传入自定义缓存实现，加入LRU淘汰策略。理解这些细节后，SWR才能真正成为项目中稳定可靠的数据层。