RSC与缓存策略最佳实践解析

RSC 的出现，让缓存策略从简单的“过期时间管理”升级到了更精细的组件级缓存编排。如果你还在用传统的全页面缓存（Page Cache）或者只依赖 CDN 的静态资源缓存来对付 React 应用，那很可能已经跟不上 RSC 架构下的性能天花板了——毕竟，RSC 重新定义了“什么是静态内容”。

缓存核心：序列化传输决定了缓存粒度

RSC 的核心机制决定了服务端组件返回的不是 HTML，而是序列化后的 JSON 描述（React Flight 格式）。这意味着你常见的“HTML 片段缓存”模式直接失效了。取而代之的是，你可以对数据层进行更精确的缓存：fetch 请求本身、数据库查询结果、甚至是跨请求共享的计算值。最佳实践的第一条：永远不要试图缓存序列化后的 RSC 输出，而是缓存产生它的原始数据。

举个例子，一个包含商品详情和用户评论的页面，商品详情是相对静态的（每 30 分钟更新一次），评论是动态的（实时变化）。传统 SSR 需要两个查询完成后才能生成 HTML，缓存粒度是整页。RSC 加上流式渲染（Streaming）后，商品详情组件可以配合 cache() 和 force-cache 做到 30 分钟的主动缓存，而评论组件用 no-store 保证实时性。这样一来，页面主体部分几乎总是命中缓存，只有评论模块会重新请求数据——缓存命中率从 70% 提升到了 95% 以上。

别让缓存策略“打架”：三个层级要分开

我在一个 Next.js 的 App Router 项目中看到过团队把 Cache-Control 全设成 s-maxage=86400，结果动态数据的 RSC 组件被 CDN 缓存了一天，用户看到的评论永远是一天前的。这其实暴露了 RSC 下缓存策略需要分三层考虑：

第一层：数据缓存（Server-side）

使用 React 的 cache() 包装数据获取函数，配合 fetch 的 cache: 'force-cache'，适用于配置数据、字典表、公共文章内容。注意 cache() 只在单个请求的生命周期内生效，跨请求需要配合持久化缓存（如 Redis）。一个常用的模式是：开发阶段用内存缓存，生产环境用 Redis 做共享缓存，并设置合理的 TTL。

第二层：流式渲染的 Suspense 边界缓存

RSC 支持对每个 Suspense 边界单独缓存。比如仪表盘的销售图表组件，数据每小时更新一次，你可以将它包裹在 Suspense 中，并为该组件的数据获取设置 next.revalidate = 3600。当这个区域的缓存未过期时，React 不会重新执行该组件的服务端逻辑，直接复用上次生成的 RSC payload。比较反直觉的是，revalidate 时间不是按请求计时的，而是基于每段 RSC 输出自身的“年龄”，这意味着你甚至可以让不同边界拥有不同的更新频率。

第三层：CDN 与边缘缓存（Edge）

对 RSC 的 HTTP 响应，CDN 应该缓存的是序列化后的 payload（即内容类型为 text/x-component 的响应）。关键点：不要对包含动态客户端组件（'use client'）的 RSC 输出进行长时间缓存，因为客户端组件生成的 HTML 片段需要与 JS 包同步。最佳做法是只对纯服务端组件的 RSC 响应（即不包含任何客户端组件边界的路由）设置 CDN 缓存，并配合 stale-while-revalidate 策略。

一个真实的反面案例：过度缓存导致数据不一致

之前帮一个团队排查问题：他们的商品详情页中使用 RSC 获取价格，配置了 'Cache-Control': 'public, max-age=300'，同时 CDN 也缓存了 5 分钟。问题是，后台运营修改价格后，用户看到的还是旧价格，直到 5 分钟后才能刷新。为什么不用 revalidateTag 或 revalidatePath？因为他们的 RSC 组件是自动缓存的，没有手动触发失效的机制。解决方案：对于这类强一致性的数据，直接使用 cache: 'no-store'，让服务器每次都重新获取，但利用 RSC 的流式渲染让页面其他部分（如图片、描述）从缓存中读取，整体性能依然不错。

一个实用的原则：如果是用户自己产生的数据（购物车、评论、订单），一律不缓存服务端组件；如果是全局性的、写入不频繁的数据（商品 SPU、文章内容），用 force-cache 加上按需失效（revalidatePath）。

缓存策略的工具箱：别忘了 Incremental Cache

RSC 与静态生成（SSG）结合时，别忘了增量缓存（Incremental Static Regeneration 的变体）。在 Next.js App Router 中，通过在页面组件或布局中设置 dynamic = 'force-static' 并配置 revalidate，可以让整个路由的 RSC 输出被缓存为静态文件，同时按间隔重新生成。但这里有个坑：如果这个页面中包含客户端组件，静态缓存会包含该客户端组件的打包信息，一旦客户端代码更新，静态文件中的引用会失效。因此，建议只有纯服务端组件的路由（如内容详情页）才启用完全静态缓存，其他情况优先使用流式 + 逐区域缓存。

说到底，RSC 的缓存最佳实践不是一套死规则，而是根据数据特性、交互需求、更新频率进行动态平衡。能用 200 行代码搞定的缓存逻辑，就别上分布式缓存集群；能靠 cache() 和 fetch 参数解决的，别强行搭 CDN 层。工具越简单，越难出错。