OpenMontage 前端性能指南：使用 SWR 实现自动请求去重（Deduplication）的完整实践-开发者社区

OpenMontage 前端性能指南：使用 SWR 实现自动请求去重（Deduplication）的完整实践

【免费下载链接】OpenMontageWorld's first open-source, agentic video production system. 12 production pipelines, 100+ tools, 700+ agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage

导读

本篇文章聚焦 OpenMontage 仓库中vercel-react-best-practices技能体系下的核心前端规则——使用 SWR 进行客户端数据的自动去重、缓存与再验证。该规则属于「Client-Side Data Fetching（客户端数据获取）」分类，被标记为 MEDIUM-HIGH 影响等级，面向所有 React / Next.js 组件的编写、评审与重构场景。读完本文，你将掌握 SWR 的三种典型用法（常规获取、不可变数据、突变更新），理解请求去重背后的工作原理，并能用仓库内的源码证据判断一条 React 数据获取代码是否违反该规范。

规则出处与定位

本规则源自仓库中的规则文件 client-swr-dedup.md，其 frontmatter 声明如下：

title: Use SWR for Automatic Deduplication impact: MEDIUM-HIGH impactDescription: automatic deduplication tags: client, swr, deduplication,>function UserList() { const [users, setUsers] = useState([]) useEffect(() => { fetch('/api/users') .then(r => r.json()) .then(setUsers) }, []) }

这段代码的问题在于：

每次挂载UserList组件都会触发一次全新的网络请求，哪怕请求的 URL 完全相同；
组件卸载后，setUsers仍可能被异步回调调用，引发「在已卸载组件上设置状态」的告警；
没有缓存，页面切换回来或组件重新挂载时数据必须重新拉取；
数据过期后没有任何自动再验证（revalidation）机制。

正确写法（多个实例共享同一次请求）：

import useSWR from 'swr' function UserList() { const { data: users } = useSWR('/api/users', fetcher) }

核心差异在于：SWR 以「请求 key」（这里是/api/users）为维度做全局去重。无论有多少个组件实例使用同一个 key 调用useSWR，同一时间窗口内只有一个网络请求会被真正发出，其余实例直接复用该请求的结果；请求返回后，数据会被写入缓存，后续所有订阅该 key 的组件都能拿到一致的数据，并在窗口期、聚焦、重连等时机自动再验证。

去重与再验证的底层机制

从规则本身的表述（"SWR enables request deduplication, caching, and revalidation across component instances"）可以提炼出三个核心能力：

Deduplication（去重）：同一 key、同一时间片内的并发订阅合并为一次请求，减少服务器压力与网络往返；
Caching（缓存）：请求结果在客户端缓存，组件重新挂载、路由切换回来时零延迟读取；
Revalidation（再验证）：缓存不会永远陈旧，SWR 会在dedupingInterval之外通过聚焦、重连、定时器等策略触发后台重新获取，兼顾速度与新鲜度。

默认情况下 SWR 的dedupingInterval为 2000ms，即 2 秒内相同 key 的请求只会真正发出一次；该值可通过第三个参数全局或按请求覆盖，例如useSWR('/api/users', fetcher, { dedupingInterval: 5000 })。这些配置语义来自 SWR 官方 API（规则文末亦引用了官方文档站点），属于库的公开契约。

三种典型用法：常规、不可变、突变

规则文件给出了三个可直接落地的场景，这里逐一展开。

场景一：常规数据获取（推荐默认）

import useSWR from 'swr' function UserList() { const { data: users } = useSWR('/api/users', fetcher) }

fetcher是接收 key 并返回 Promise 的函数，典型实现为(url) => fetch(url).then(r => r.json())。项目中的标准做法是把 fetcher 提取为模块级常量，避免每次渲染重建函数引用。值得留意的是，这里的去重能力天然对「多组件共享同一资源」友好：例如列表页与统计卡片同时读取/api/users，二者共享一次请求与同一份缓存，接口压力减半。

场景二：不可变数据（Immutable Data）

对于配置文件、静态元数据这类挂载后不需要再验证的数据，规则推荐使用useImmutableSWR：

import { useImmutableSWR } from '@/lib/swr' function StaticContent() { const { data } = useImmutableSWR('/api/config', fetcher) }

useImmutableSWR通常由团队在@/lib/swr中统一封装（规则中直接引用了该模块路径），其本质是useSWR(key, fetcher, { revalidateIfStale: false, revalidateOnFocus: false, revalidateOnReconnect: false })的预配置版本。使用它的收益是：静态内容在首次请求后不再触发任何自动再验证，减少无意义的网络请求，同时仍保留去重与缓存带来的「多实例零重复请求」收益。

场景三：突变（Mutation）

对于写操作，规则推荐使用useSWRMutation，它把「请求」与「更新 UI 的触发器」解耦：

import { useSWRMutation } from 'swr/mutation' function UpdateButton() { const { trigger } = useSWRMutation('/api/user', updateUser) return <button onClick={() => trigger()}>Update</button> }

useSWRMutation与useSWR的关键区别是：它不会在挂载时自动发起请求，只有在调用trigger()时才执行写操作，因此非常适合表单提交、按钮触发类场景。updateUser是接收(url, { arg })的 mutation 函数，trigger(arg)传入的载荷会通过arg透传。配合mutate可以在写成功后对相关 key 做本地乐观更新或重新验证，形成完整的「读-写-再验证」闭环。

同族规则与体系关联

为了让该规则在真实项目中可落地，仓库技能还提供了互补规则：

client-event-listeners.md：同样利用 SWR 生态，通过useSWRSubscription（swr/subscription）把 N 个组件实例的全局键盘事件监听合并为 1 个监听器，把「去重」思想从请求延伸到事件；
服务端侧的server-cache-react规则（React.cache()做每请求级去重）与server-cache-lru规则（LRU 跨请求缓存）与本文的客户端去重形成前后端呼应——客户端用 SWR，服务端用React.cache()/LRU，共同消除整条链路上的冗余 I/O；
技能元数据 SKILL.md 的「When to Apply」章节明确列出触发场景：编写新 React 组件或 Next.js 页面、实现客户端或服务端数据获取、评审性能问题、重构既有代码、优化 bundle 与加载时间。

在 OpenMontage 的技能编排体系中，该技能作为vercel-react-best-practices加载项被 Agent 用于 React/Next.js 代码的自动生成与自动评审：Agent 在产出任何带fetch/useEffect数据加载逻辑的组件前，会对照 4.3 这条规则检查是否已切换为 SWR；评审时则重点抓「重复请求」「无缓存」「无再验证」三处反模式。