局部预渲染与并发渲染详解

了解Next.js的局部预渲染与React的并发渲染是如何通过让框架调度和分步处理任务，而非将渲染视为一个阻塞性整体，从而解决应用运行缓慢问题的。

1346 词

现代 React 和 Next.js 的性能优化始终围绕同一个核心理念：迫使整个页面或整个渲染过程作为一个不可分割的单一单元来运行，正是这一原因导致应用显得缓慢。有两种技术从不同角度解决这一问题——部分预渲染允许单个 Next.js 路由混合使用静态内容和动态内容，而并发渲染则让 React 能够中断并重新排序浏览器内的任务。二者共同揭示了一个值得理解的规律：性能提升越来越不是通过编写“更快”的代码来实现，而是让框架以更智能的方式安排和执行任务。

传统的全有或全无的渲染模式

很长一段时间里，Next.js 页面只有两种可选的渲染模式：

静态生成（SSG）——由于页面是在事先构建好的，因此加载速度很快，但内容会在下一次重新生成之前变得过时。
服务器端渲染（SSR）——内容始终是最新的，但每次请求都必须等待最慢的那部分数据处理完成才能返回结果。

问题在于，大多数实际页面都无法完全归入这两类之中。例如产品页面大多属于静态内容——布局、导航和营销文案不会因每次请求而改变——但它也包含一些真正的动态元素，比如购物车图标或实时库存计数器。仅仅为了保持某个小组件更新而通过SSR渲染整个页面，意味着要为那些并不需要此功能的 content支付全部的服务器渲染成本。

让同一个路由同时具备静态和动态特性

部分预渲染（PPR）正是为填补这一空白而存在的。它能让单个路由立即输出静态外壳，而其中的动态内容则会在数据准备就绪时立即流式加载——无需单独的页面，也无需在getStaticProps和getServerSideProps之间切换。

// app/product/[id]/page.tsx
import { Suspense } from 'react';
import ProductShell from '@/components/ProductShell';
import LiveInventory from '@/components/LiveInventory';

export default function ProductPage({ params }: { params: { id: string } }) {
  return (
    <ProductShell productId={params.id}>
      {/* static instantly, no waiting on the network */}
      <Suspense fallback={<InventorySkeleton />}>
        {/* streamed in once the dynamic data resolves */}
        <LiveInventory productId={params.id} />
      </Suspense>
    </ProductShell>
  );
}

其实现机制基于Suspense边界。置于该边界之外的内容会在构建时被预渲染并立即提供；而位于其内部的内容则会在请求时才进行计算并流式传输。整个思路就是：一个文件，一个路由，两种渲染策略共存。

这种架构带来了多项实际优势。由于静态内容直接从边缘节点提供，而无需为每个请求重新计算，因此首次传输字节的时间得以缩短。同时也不需要全页加载状态——访问者可以立即看到页面中有实际意义的部分，而较小的动态内容则会在加载完成后逐步呈现。与维护独立的静态页面和服务器渲染页面相比，其认知负担也更轻，因为只需处理一个路由和一个结合了多种渲染策略的文件。Next.js团队将这一目标描述为在无需承担传统架构折衷的情况下，实现静态渲染与动态渲染的双重优势。

几条实用准则能让 PPR 在实际生产环境中发挥效用。只需在真正动态的部分周围设置严格的 Suspense 边界，否则包裹过多内容反而会违背预渲染的意义。 fallback 骨架结构应保持轻量，因为这些 fallback 本身也是静态渲染外壳的组成部分。如果使用 TypeScript，请在静态外壳与动态加载的组件之间定义明确的属性规范，以便两者在发展过程中保持同步。测试时，可在浏览器开发者工具中将连接速度设置为类似 3G 的慢速模式——在真实的网络条件下，PPR 的优势会比在快速本地连接下更为明显。

如果您的团队正在使用 Next.js 14 或更高版本，建议先在单个路由上尝试 PPR，再考虑在整个应用中推广使用。这并非营销术语，而是一种渲染策略，能够真正体现真实页面的运行方式——部分内容为静态的，部分内容为实时的，同时存在。

将相同理念应用于客户端渲染

部分预渲染解决了服务器端和网络层面的静态与动态问题。而随 React 18 引入并在 React 19 中进一步完善的并发渲染，则解决了浏览器内的类似问题：React 不再需要在“立即渲染所有内容”和“暂不渲染任何内容”之间做选择，而是可以立即渲染部分内容，其余内容则稍后处理。

在 React 18 之前，渲染是同步且会阻塞操作的。每次状态更新都会触发重新渲染，而且无论何种情况都会执行完毕——即便这意味着在 React 处理整个状态树时会导致滚动或输入操作暂停。

并发渲染改变了这一行为。现在 React 可以在渲染过程中暂停，将输入或点击等紧急更新置于长列表过滤等非紧急更新之前处理，如果出现更新的更新使得之前的工作不再必要，则会丢弃这些正在进行中的任务。重要的是，这并非需要从头学习的新的 API——它只是在你已使用的钩子背后运行的另一种调度模型而已。

支持并发调度的钩子

useTransition 允许你将某个状态更新标记为非紧急的，这样在后台处理该更新时，React 仍能保持界面的响应性。

function ProductSearch() {
  const [query, setQuery] = useState("");
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  function handleChange(e) {
    const value = e.target.value;
    setQuery(value); // urgent — keep input snappy

    startTransition(() => {
      // non-urgent — can be interrupted
      setResults(filterProducts(value));
    });
  }

  return (
    <>
      <input value={query} onChange={handleChange} />
      {isPending && <span className="text-gray-400">Updating…</span>}
      <ResultsList items={results} />
    </>
  );
}

通过这种模式，即使在后台对数千个项目进行过滤时，用户在搜索框中输入内容依然流畅。

Suspense在客户端扮演的角色与它在服务器端的PPR功能类似：它不会在数据加载时阻塞整个页面，而是让UI的各个部分独立渲染。结合Next.js App Router后，它还能让服务器组件逐步加载到页面中，而不会延迟整体加载过程。

useDeferredValue则用于处理另一个相关但不同的场景：即由来自props或上下文的值而非组件本地状态引发的昂贵重新渲染问题。它允许React在有空闲时间时再重新计算这些耗资源的部分。

对于同时使用 React、Next.js、TypeScript、Redux 和 Tailwind CSS 的团队而言，这种调度模型的重要性不仅体现在各个钩子函数上——Redux Toolkit 中的新兴异步模式以及 Next.js Server Actions 在底层的工作方式，都依赖于 React 目前所提供的相同并发调度机制。并发并非可直接开启的功能；只有当组件的结构允许其渲染被中断并重新继续时，React 才会自动应用这一能力。

需要记住的内容

无论采用哪种技术，其核心原理都是一样的：将整个页面或整个渲染结果视为一个不可分割的整体，正是这一做法导致了性能迟缓，而非代码效率低下。并发渲染并非旨在编写更快的代码，而是更智能地调度现有的代码。在实践中，这意味着使用 useTransition 推迟非紧急的状态更新，利用 Suspense 流式加载数据，并在性能较低的设备上进行测试，因为正是在这些设备上才能最明显地看到并发带来的优势。结合服务器端的部分预渲染，这些工具能够让单个路由或单个组件树立即提供静态内容，而动态内容则仅在准备就绪时再流式加载——实现了两种渲染方式的优点，无需围绕其中任何一种极端方式重新构建架构。