React 缓存机制（Cache）：服务器组件中对数据请求的自动去重与共享逻辑分析 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

大家好，欢迎来到今天的“React 服务器端组件（RSC）生存指南”讲座。我是你们的讲师，一个在 React 代码里摸爬滚打多年的老司机。

今天我们要聊一个话题，听起来有点枯燥，但如果你做 React 开发，它简直就是你的救命稻草。这个话题就是：React 缓存机制。

别急着打哈欠，我知道“缓存”这两个字听起来像是后端数据库里的东西，或者是浏览器本地存储里的饼干。但在 React Server Components（RSC）的世界里，缓存是个魔术师。它能让你从“服务器被请求得像发情的公牛”变成“服务器优雅地喝茶，数据像流水一样送来”。

第一章：想象一下，你是个没有脑子的服务员

首先，我们得回到问题的本质。在传统的 React（或者说是 React Client Components）里，组件渲染是发生在用户浏览器的 JavaScript 引擎里的。

假设你开了一家餐厅，你是服务员。用户点了“牛肉面”。你跑去厨房说：“给我一碗牛肉面。” 厨房做了一碗，端上来。
用户又点了“牛肉面”。
你又跑去厨房说：“给我一碗牛肉面。”
厨房：“我又做一碗？”
你：“是啊，又要一碗。”
厨房：“……”

这就是没有缓存的情况。在 React Server Components 里，如果我们不处理，服务器就是那个厨房。你的组件就是那个服务员。

// server-component.js
import { fetch } from 'react-fetch'; // 假装有这个

async function UserProfile() {
  // 第一个请求
  const user = await fetch('/api/user/1').then(r => r.json());

  // 第二个请求
  const posts = await fetch('/api/posts?userId=1').then(r => r.json());

  return (
    <div>
      <h1>{user.name}</h1>
      <ul>
        {posts.map(post => <li key={post.id}>{post.title}</li>)}
      </ul>
    </div>
  );
}

看起来很正常，对吧？但是，如果你的 UserProfile 组件被渲染了两次（也许是因为父组件重新渲染了，或者你在同一个页面上用了两次 UserProfile），或者你的 PostList 组件里又请求了一遍用户信息，那么服务器就要工作两倍、三倍。

在 RSC 的世界里，服务器的资源是宝贵的。虽然服务器的算力比浏览器强，但网络带宽和数据库连接池也是有上限的。如果在一个页面里，有十个组件都调用了同一个 API，服务器就会发出十次请求。这不仅仅是浪费 CPU，更是浪费了数据库的查询时间。

所以，我们需要一个“聪明”的服务员。他不会每次都跑回厨房，而是会先看看自己的脑子里有没有存过这个菜。这就是我们要讲的 React 缓存机制。

第二章：`use` Hook —— 隐藏在组件里的缓存宝盒

React 从 18 版本开始引入了一个非常神奇的工具，叫做 use。注意，这里不是 useState，也不是 useEffect，而是 use。

use 的作用非常简单粗暴：它缓存异步函数的执行结果。

只要你在服务端组件里用 use 包裹一个异步函数（通常是 fetch），React 就会记住这个结果。如果后续再次调用这个函数，React 会直接返回缓存的结果，而不是再次执行函数。

让我们看看代码怎么写。注意，这里的 use 只能在服务端组件里用，客户端组件里用它是没用的（或者说不生效）。

// server-component.js

// 定义一个获取数据的函数
async function getUserData(id) {
  // 模拟网络延迟
  const res = await fetch(`https://jsonplaceholder.typicode.com/users/${id}`);
  if (!res.ok) throw new Error('Failed to fetch user');
  return res.json();
}

export default async function UserProfile() {
  // 第一次调用，服务器发起请求
  const user = use(getUserData(1));

  // 第二次调用，React 直接从内存里拿出缓存的数据
  // 这时候服务器根本不需要再发一次请求！
  const user2 = use(getUserData(1));

  return (
    <div>
      <h1>User Cache Demo</h1>
      <p>First call result: {user.name}</p>
      <p>Second call result: {user2.name}</p>
    </div>
  );
}

看到了吗？user 和 user2 是同一个对象。React 帮你把这两个调用合并成了一个。

第三章：自动去重 —— 不仅仅是重复调用

这是最酷的部分。缓存不仅仅是针对同一个组件里的重复调用，它是针对整个组件树的。

假设你的页面结构是这样的：

PageLayout (主容器)
- Header (头部)
- Sidebar (侧边栏)
- MainContent (主要内容)

这三个兄弟组件都在渲染。现在，Header 想要获取用户信息，Sidebar 也想获取用户信息。

在以前，这会导致两个请求。现在，有了 use，React 会自动去重。

// Header.jsx
async function Header() {
  const user = use(getUserData(1));
  return <div>Hello, {user.name}</div>;
}

// Sidebar.jsx
async function Sidebar() {
  const user = use(getUserData(1)); // 注意，这里调用了同样的函数
  return <div>User ID: {user.id}</div>;
}

// Page.jsx
export default function Page() {
  return (
    <div>
      <Header />
      <Sidebar />
    </div>
  );
}

发生了什么？

Header 开始渲染。它调用了 getUserData(1)。
React 在缓存里查找 getUserData(1)。如果不存在，它就发起请求。
请求正在处理中（Promise 正在等待）。
接下来，Sidebar 开始渲染。它也调用了 getUserData(1)。
React 再次在缓存里查找 getUserData(1)。
奇迹发生了！ React 发现缓存里已经有一个正在进行的 Promise 了。
React 不会发起新的请求。它直接把那个正在等待的 Promise 返回给了 Sidebar。
当 Header 的请求完成，Sidebar 会立即拿到数据，不用再等第二次网络请求。

这就叫自动去重。这就像你的大脑一样，第一次听到一个笑话，你笑了；第二次听到同一个笑话，你还是会笑，但你不会重新去听一遍。

第四章：Promise 共享 —— 它们是同一个东西

你可能会有个疑问：Header 拿到的是一个 Promise 对象，Sidebar 拿到的也是一个 Promise 对象。如果 Header 的请求失败了，Sidebar 也会失败吗？

答案是肯定的，因为它们共享的是同一个 Promise 实例。

这不仅仅是结果共享，而是执行流程的共享。

async function getData() {
  console.log("Fetching started..."); // 只有这一行会打印
  await new Promise(r => setTimeout(r, 1000));
  console.log("Fetching finished...");
  return { data: "Hello" };
}

function ComponentA() {
  const data = use(getData());
  console.log("ComponentA got:", data);
  return <div>A</div>;
}

function ComponentB() {
  const data = use(getData()); // 这里的 console.log 不会打印，因为 Promise 还没 resolve
  console.log("ComponentB got:", data);
  return <div>B</div>;
}

function Parent() {
  return (
    <>
      <ComponentA />
      <ComponentB />
    </>
  );
}

运行结果：

ComponentA 渲染。
use(getData) 执行。
控制台打印 Fetching started...。
ComponentB 渲染。
use(getData) 检查缓存。
发现缓存里有 Fetching started... 这个状态。
ComponentB 等待 ComponentA 的 Promise 完成。
ComponentA 打印 Fetching finished...。
ComponentB 打印 ComponentB got: { data: "Hello" }。

这解决了 RSC 中经典的瀑布流 问题。在旧的方式里，ComponentB 必须等 ComponentA 里的 fetch 完全结束（并且数据传回服务器，再传给 ComponentB）才能开始自己的 fetch。现在，ComponentB 可以和 ComponentA 并发等待同一个 Promise，极大地提高了效率。

第五章：缓存的生命周期 —— 它什么时候失效？

这是一个非常关键的问题。如果缓存一直不失效，那岂不是每次刷新页面都读旧数据？

在 React Server Components 中，缓存的失效策略是非常聪明的。

1. 页面级别的缓存：

当你第一次访问一个页面（比如 /users/1）时，React 会发起请求，并将结果缓存起来。如果你在同一个会话中，点击浏览器的“后退”按钮，React 会检测到用户还在同一个组件树上。

此时，React 会检查缓存。如果缓存是有效的，它不会重新请求数据，而是直接使用缓存。这意味着你的页面会瞬间加载，感觉不到任何延迟。

2. 依赖变化：

如果 use 的参数变了，缓存就会失效。

async function getUser(id) {
  const res = await fetch(`https://api.com/users/${id}`);
  return res.json();
}

export default function UserPage({ userId }) {
  // 如果 userId 变了，比如从 1 变成 2
  // use 会检测到依赖变化，重新调用 getUser(2)
  const user = use(getUser(userId));

  return <div>{user.name}</div>;
}

3. 页面刷新与重新构建：

当用户刷新页面时，这是一个全新的渲染过程。缓存会被清空，服务器必须重新发起请求。这是正常的，因为我们需要最新的数据。

4. 错误处理：

如果 use 内部的函数抛出了异常，或者 fetch 失败了，这个错误会被抛出到组件树中。如果你在组件树中捕获了这个错误，缓存会被保留吗？或者被清除？

通常情况下，如果 Promise 失败，后续的 use 调用会直接抛出相同的错误，而不是重新发起请求。这保证了错误的一致性。

第六章：手动控制缓存 —— `cache()` 函数

虽然 use 很好用，但有时候我们想在组件外部使用缓存逻辑，或者想更精细地控制缓存策略。React 19 提供了一个全局的 cache 函数。

import { cache } from 'react';

// 使用 cache 包装你的函数
const getCachedUserData = cache(async (id) => {
  const res = await fetch(`https://api.com/users/${id}`);
  return res.json();
});

export default async function UserProfile() {
  // 这里调用的是被 cache 包装后的函数
  const user = await getCachedUserData(1);

  // 在组件树的其他地方
  const anotherUser = await getCachedUserData(1); // 共享缓存

  return <div>{user.name}</div>;
}

cache() 和 use 的区别：

作用域： cache() 是全局的（在同一个渲染周期内）。use 是组件作用域的。
用法： use 用于在组件内部获取数据（副作用）。cache() 用于定义可以被多次调用的纯函数逻辑。
并发： 两者都能处理并发请求。但 cache() 包装的函数可以在没有组件的情况下被调用（例如在数据加载器或工具函数中）。

第七章：实战演练 —— 一个复杂的组件树

让我们来个稍微复杂点的场景，看看 React 缓存是如何在复杂的父子关系和兄弟关系中工作的。

假设我们有这样一个页面：

// page.tsx
import Profile from './components/profile';
import ActivityFeed from './components/activity-feed';
import Stats from './components/stats';

export default function UserPage({ userId }) {
  return (
    <div className="layout">
      <Profile userId={userId} />
      <div className="split-view">
        <ActivityFeed userId={userId} />
        <Stats userId={userId} />
      </div>
    </div>
  );
}

// components/profile.tsx
async function Profile({ userId }) {
  // 请求用户详情
  const user = await fetch(`/api/users/${userId}`).then(r => r.json());

  return (
    <div className="profile-card">
      <h1>{user.name}</h1>
      <Avatar user={user} /> {/* 这里嵌套了另一个组件 */}
    </div>
  );
}

// components/avatar.tsx
async function Avatar({ user }) {
  // 假设头像需要单独请求
  // 注意：这里没有传 userId，但我们可以通过 user.id 获取
  // 问题是：React 能识别出这是一个新的请求吗？
  // 如果 user.id 是一样的，React 会去重吗？

  // 答案是：不能！
  // React 的缓存是基于函数调用的。Avatar 组件的函数签名里没有 userId
  // 它依赖于 props 传入的 user 对象。
  // 如果 Profile 传过来的 user 对象变了（引用变了），Avatar 就会重新请求。

  const avatarUrl = await fetch(`/api/avatar/${user.id}`).then(r => r.json());
  return <img src={avatarUrl} />;
}

分析：

UserPage 渲染 Profile 和 ActivityFeed。
Profile 请求 /api/users/1。
ActivityFeed 请求 /api/activity/1。这两个请求是独立的。
Profile 渲染 Avatar。
Avatar 请求 /api/avatar/1。这是第三个请求。
如果 Stats 组件也渲染 Avatar，它也会请求 /api/avatar/1。这是第四个请求。

优化方案：

为了让 Avatar 也能享受缓存，我们需要把 userId 传递进去。

// components/avatar.tsx
async function Avatar({ userId }) {
  // 现在 Avatar 的函数签名里有 userId
  // 如果 Profile 和 Stats 都传了 userId=1，React 会自动去重！
  const avatarUrl = await fetch(`/api/avatar/${userId}`).then(r => r.json());
  return <img src={avatarUrl} />;
}

// components/profile.tsx
async function Profile({ userId }) {
  const user = await fetch(`/api/users/${userId}`).then(r => r.json());
  return (
    <div className="profile-card">
      <h1>{user.name}</h1>
      <Avatar userId={user.id} /> 
    </div>
  );
}

结论： React 的缓存是基于函数调用的。如果你想让多个组件共享数据缓存，你必须确保它们调用的是同一个函数，并且传入的参数（依赖）是一致的。

第八章：陷阱与注意事项 —— 别把缓存当万能药

虽然缓存很棒，但如果你用错了，也会出大问题。

1. 不能在 use 里做副作用？

其实 use 本身就是一个副作用（发起网络请求）。但是，你不能在 use 内部更新状态（useState）或者触发其他副作用（比如直接在 use 里写 console.log 是可以的，但通常我们不这么做）。

为什么？因为 use 是在渲染期间同步执行的。如果在 use 里修改了状态，会立即触发重新渲染。如果在重新渲染期间又调用了 use，可能会导致无限循环或者不可预测的行为。

2. 缓存是组件树级别的，不是全局应用级别的

这很重要。如果你在 A 组件里缓存了数据，然后你跳转到了 B 组件，B 组件里如果调用了同样的函数，B 组件是拿不到 A 组件的缓存的。

只有当 B 组件被渲染时，React 才会创建新的缓存条目。这保证了不同页面的数据是隔离的，避免了一个页面的请求污染了另一个页面的数据。

3. 缓存键与引用

React 的缓存是基于函数引用和参数的。如果你用 useMemo 或者 useCallback 包装了你的 fetch 函数，并且依赖项变了，缓存就会失效。

// 这是一个糟糕的例子
function BadComponent({ userId }) {
  // 每次渲染，getUser 都是一个新的函数引用
  const getUser = async (id) => { ... };

  const data = use(getUser(userId));
  // React 无法识别这是同一个函数调用，因为 getUser 在每次渲染时都是新的
}

4. 服务器端的副作用

虽然 use 可以发请求，但不要在组件里做太多逻辑。保持组件纯粹。如果你有复杂的初始化逻辑，应该放在 page.tsx 或者数据加载器里。

第九章：调试 —— 如何确认缓存生效了？

有时候你不确定 React 到底有没有缓存。你可以通过 React DevTools 的 React Server Components 面板来查看。

当你使用 use 或者 cache() 时，React 会生成一些元数据。

此外，你可以在代码里加一些日志来验证。

async function getPost(id) {
  console.log(`[Cache Check] Fetching post ${id}...`);
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${id}`);
  return res.json();
}

function PostList() {
  const post1 = use(getPost(1));
  const post2 = use(getPost(1)); // 第二次调用
  const post3 = use(getPost(2)); // 不同的数据
  return <div>...</div>;
}

如果控制台只打印了 Fetching post 1... 和 Fetching post 2...，而没有打印两次 Fetching post 1...，恭喜你，缓存生效了！

第十章：未来的演进

React 团队一直在优化缓存机制。在未来的版本中，我们可能会看到更细粒度的缓存控制，比如可以设置缓存过期时间（虽然 RSC 默认是即时加载，但我们可以模拟 TTL），或者更智能的缓存策略，比如基于请求头（ETag）的缓存。

但现在的 use 和 cache() 已经足够强大，足以应付 90% 的服务端数据获取场景。

总结：拥抱缓存，拥抱性能

好了，同学们，今天的讲座就到这里。

我们回顾一下今天学到的核心内容：

痛点：在 React Server Components 中，没有缓存会导致重复请求，浪费服务器资源。
解药：使用 use Hook 来缓存异步函数的执行结果。
机制：React 自动去重，并且共享正在进行的 Promise。
技巧：使用 cache() 函数在组件外部定义可复用的缓存逻辑。
关键：确保组件的依赖参数一致，以触发缓存共享。

记住，作为一名资深开发者，你的目标不是写出能跑的代码，而是写出高效的代码。学会使用 React 的缓存机制，就像学会了给服务器装上了一个“大脑”。它不再是一个只会傻傻重复执行命令的机器，而是一个懂得记忆、懂得节约、懂得并发的高手。

下次当你写代码时，如果你的组件树里有多个地方需要同一个数据，请毫不犹豫地拿起 use。让你的服务器少发几次请求，让用户的页面加载得更快一点，哪怕只是一点点。

谢谢大家！