React Suspense 数据加载怎样避免瀑布请求

React Suspense 数据加载要避免瀑布请求，关键不是把所有内容放进一个巨大组件，而是把“请求何时开始”和“组件何时显示”拆开：彼此独立的数据在同一个加载入口提前创建 Promise，组件用稳定的 Promise 读取，Suspense 再按内容块安排 fallback。只有真正依赖上一个结果的请求才保留先后顺序。

官方地址：https://react.dev/

如果用户资料和通知列表互不依赖，就应该在页面加载入口同时启动；如果 Promise 是在子组件渲染时临时创建，父子层级和重复渲染都会把网络请求重新排成串行。

先找出真正的瀑布请求

典型瀑布有三种。第一种是父组件先请求详情，拿到结果后才把子组件挂载，子组件随后请求评论或推荐；第二种是多个 useEffect 按渲染顺序启动请求；第三种是组件渲染时才调用一个未缓存的异步函数。它们的共同点是：下一条请求的开始时间被不必要地推迟了。

先画出请求依赖关系，再决定是否并行。用户资料和通知列表都只依赖路由里的 userId，可以并行；用户的订单必须先拿到用户区域或权限信息时，就不能为了“并行”而删除这个业务依赖。

在同一加载入口启动独立请求

把请求启动放到路由加载器、服务端组件或页面入口，让独立 Promise 尽早开始。下面的示例只演示数据组织方式，真实项目应把缓存、鉴权和取消请求交给所用框架或数据层。

// data.js
const promiseCache = new Map();

function requestJson(url) {
  // 同一个地址复用同一个 Promise，避免重复渲染再次发起请求。
  if (!promiseCache.has(url)) {
    const promise = fetch(url).then((response) => {
      // 网络响应成功不等于业务成功，先把 HTTP 错误转成可捕获异常。
      if (!response.ok) throw new Error(`请求失败：${response.status}`);
      return response.json();
    });
    promiseCache.set(url, promise);
  }
  return promiseCache.get(url);
}

export function createPageResources(userId) {
  // 两个请求只依赖 userId，因此在同一个入口同时创建。
  return {
    profilePromise: requestJson(`/api/users/${userId}`),
    noticesPromise: requestJson(`/api/users/${userId}/notices`),
  };
}

这里的重点不是 Map 本身，而是创建 Promise 的时机和生命周期。页面入口每次接到相同的 userId 都要取得稳定的 Promise；不要在组件函数里直接写 use(fetch(url))，因为组件重新渲染时会创建新的 Promise。

用稳定 Promise 和边界控制内容揭示

use 读取 Promise 时，Promise 未完成就会让最近的 Suspense 边界显示 fallback，完成后再显示内容。边界应该按用户能理解的内容块划分，而不是每个小组件都包一层，否则页面会同时闪动很多占位区域。

// Page.jsx
import { Suspense, use } from 'react';
import { ErrorBoundary } from 'react-error-boundary';

function Profile({ promise }) {
  // Promise 已在页面入口创建，这里只负责读取结果。
  const profile = use(promise);
  return 
欢迎，{profile.displayName}
;
}

function Notices({ promise }) {
  // 通知列表和资料互不依赖，可以在各自边界内并行揭示。
  const notices = use(promise);
  return 
{notices.map((item) => 
{item.text}
)}
;
}

export function Page({ resources }) {
  return (
    数据加载失败，请稍后重试。}>
      正在加载用户资料……}>
        正在加载通知……}>
        
  );
}

两个边界并不会让请求变成并行；并行发生在 createPageResources 创建 Promise 的时刻。边界只决定加载中的内容如何显示，以及资料已完成但通知仍在等待时页面是否能先给出可用信息。

只保留真实的数据依赖

有些瀑布不是实现错误，而是业务依赖导致的。例如订单接口必须使用用户接口返回的区域代码，这时可以先请求用户，再用区域代码请求订单。但如果订单接口其实接收路由已有的 userId，就不应该先等待整份用户资料。

可以用下面的判断表快速调整：

刷新、预加载和失败重试怎么安排

用户点击刷新时，不要让新请求把已显示的整块内容立即替换成空白。可以清理目标缓存，在 startTransition 中把新的 Promise 放入状态，让 React 在数据准备期间尽量保留旧内容。用户即将打开的面板，则可以在悬停事件中调用同一个缓存函数，点击时直接读取已经开始的请求。

// RefreshButton.jsx
import { startTransition, useState } from 'react';

export function RefreshButton({ reload }) {
  const [pending, setPending] = useState(false);

  function handleRefresh() {
    // 由数据层清理旧缓存并返回新的稳定 Promise。
    startTransition(() => {
      setPending(true);
      reload().finally(() => setPending(false));
    });
  }

  return 
    {pending ? '刷新中……' : '刷新'}
  ;
}

失败处理要放在 Error Boundary 或数据层，而不是只在 Suspense 的 fallback 里写“加载中”。加载中、请求失败和空数据是三种不同状态；重试时要替换失败的 Promise，并保证新的请求仍然进入同一套缓存和边界管理。

常见问题

把多个组件放进同一个 Suspense 就能消除瀑布吗？

不能。Suspense 控制显示时机，不负责自动把 Effect 或普通 fetch 改成并行。必须先让独立请求在同一入口开始，再根据体验选择一个或多个边界。

为什么每次渲染都创建 Promise 会反复显示 fallback？

因为挂起发生后 React 可能重新尝试渲染；如果每次尝试都得到新 Promise，组件永远拿不到稳定的已完成资源。把 Promise 放进框架提供的缓存、服务端加载器或模块级缓存，并在组件里只读取它。

所有请求都应该并行吗？

不是。没有数据依赖的请求适合并行，依赖前一个结果的请求必须保留顺序。优化目标是去掉不必要的等待，而不是制造更多无效请求。