Next.js PPR 部分预渲染：混合静态与动态数据的下一代渲染方案

你是不是也遇到过这样的场景：一个电商商品详情页，商品标题、价格、描述这些静态内容加载飞快，但用户评论、库存状态、个性化推荐这些动态数据却要等上好几秒，整个页面就卡在那里，用户体验直线下降。

或者，你精心构建了一个博客，文章内容通过静态生成（SSG）秒开，但侧边栏的“最新文章”列表、文章底部的“相关推荐”，每次访问都要重新请求接口，拖慢了整个页面的交互就绪时间。

这背后是一个经典的性能难题：如何让一个页面同时拥有静态内容的极速加载，又能无缝集成实时变化的动态数据？传统的解决方案，无论是纯静态生成（SSG）还是服务端渲染（SSR），似乎都难以两全其美。SSG 快但数据过时，SSR 数据新但首屏慢。

今天我们要深入探讨的PPR（Partial Prerendering，部分预渲染），正是 Next.js 团队为破解这一困局提出的下一代渲染模型。它不是一个简单的功能更新，而是一种架构思维的转变。很多人初次接触 PPR，会误以为它只是“SSG + SSR 的简单缝合”，但它的核心价值远不止于此。

本文将带你彻底弄懂 PPR：它到底解决了什么根本问题？其“静态骨架 + 动态流式填充”的魔法是如何实现的？在 Next.js 中如何从零开始实践？以及，在拥抱这项新能力时，你需要避开哪些“坑”？无论你是正在为页面性能瓶颈头疼的开发者，还是对前端渲染演进趋势感兴趣的技术人，这篇文章都将提供清晰的路径和可落地的代码。

1. PPR 要解决的，到底是什么问题？

在深入技术细节之前，我们必须先厘清 PPR 瞄准的靶心。前端渲染的演进，始终围绕着“加载性能”与“数据新鲜度”这对矛盾展开。

• 客户端渲染（CSR）：所有内容由 JavaScript 在浏览器中动态生成。首屏白屏时间长，对 SEO 不友好，但交互后的动态更新体验流畅。
• 服务端渲染（SSR）：在服务器生成完整的 HTML 发送给浏览器。解决了首屏和 SEO 问题，但每个请求都需要服务器执行，增加了服务器负载和响应时间（TTFB）。
• 静态站点生成（SSG）：在构建时生成所有页面的 HTML。拥有极致的加载速度和缓存能力，但数据一旦生成就无法更新，除非重新构建。

现实中的页面往往是混合体：一部分内容很少变化（如文章正文、产品描述），另一部分则需要实时或个性化数据（如用户信息、实时报价、评论列表）。

传统的混合方案及其痛点：

1. SSG + Client-side Fetching（客户端获取）：先输出静态 HTML，然后在客户端用 JavaScript 获取动态数据并渲染。这会导致“布局偏移”（CLS）和“内容闪烁”，动态区域先空着或显示 Loading，体验割裂。
2. SSR Everything（全量服务端渲染）：即使页面大部分是静态的，也因为少量动态数据而让整个页面走 SSR。这牺牲了本可以缓存起来的静态部分的性能，让服务器做了大量重复工作。
3. 手动拆分成多个请求/组件：开发者需要精细地划分组件，分别处理它们的数据获取和渲染策略，代码复杂度高，且容易出错。

PPR 的核心主张是：为什么不能按需选择渲染策略？让页面的静态部分享受 SSG 的极速，同时让动态部分以非阻塞的方式流式注入。它要解决的不是“能不能做”的问题，而是“如何做得更简单、更高效、更原生”的问题。其目标是为每个页面组件自动应用最合适的渲染策略，让开发者从繁琐的优化工作中解放出来，专注于业务逻辑。

2. PPR 的核心原理：静态骨架与动态“流式洞”

理解 PPR，关键在于两个概念：静态骨架（Static Shell）和动态“流式洞”（Streaming Hole）。

想象一下页面是一个石膏雕像。传统 SSG 是做一个完整的实心雕像；传统 SSR 是每次请求都现场雕刻一个。而 PPR 的做法是：

1. 预铸静态骨架：在构建时（或首次访问时），先用快速、确定的数据生成页面中所有静态部分的 HTML。这就像一个雕像的骨架和基本形态，它是立即可见的、稳定的。
2. 标记动态“洞”：对于需要动态数据的组件，PPR 不会让它们阻塞骨架的生成。而是在生成的静态 HTML 中，为这些组件预留出一些特殊的占位符，我们称之为“流式洞”。
3. 非阻塞流式填充：当用户请求页面时，服务器会立刻发送静态骨架的 HTML，让浏览器能立即开始渲染和显示。与此同时，服务器并行地获取各个动态“洞”所需的数据。每个数据一旦准备好，就通过同一个 HTTP 连接，以流（Stream）的形式，将对应的 HTML 片段“推”给浏览器。
4. 渐进式水合：浏览器接收到动态片段的 HTML 后，会将其填充到对应的“洞”中。同时，与这些片段相关的 JavaScript 代码（组件逻辑）也会被渐进式地加载和执行（水合），使动态组件变得可交互。

这个过程带来了几个关键优势：

• 极速的首屏渲染（FCP）：用户几乎瞬间看到页面主体框架和静态内容。
• 可交互时间（TTI）不阻塞：动态数据的加载不再阻塞整个页面的渲染。
• 高效的服务器资源利用：静态部分被高效缓存，动态部分并行处理。
• 简化的开发者体验：开发者通常只需要声明“这个组件是动态的”，框架会自动处理复杂的流式传输逻辑。

3. 环境准备：在 Next.js 中开启 PPR 之旅

PPR 作为一项前沿特性，在 Next.js 中正处于积极开发和演进阶段。因此，环境的准备至关重要。

核心要求：

• Node.js: 18.17 或更高版本。建议使用 LTS 版本以保证稳定性。
• Next.js: 目前，PPR 特性需要在Next.js 15的 Canary 版本中实验性启用。它是 Next.js 对 React 18+ 流式服务器组件和 Suspense 深度集成的成果。

创建项目与启用 PPR：

1. 创建新的 Next.js 项目：如果你从零开始，使用官方命令创建。注意，PPR 目前可能需要特定的实验性版本。

   npx create-next-app@latest my-ppr-app

   在创建过程中，CLI 会询问一系列配置。对于 PPR，关键选择是：

   • 是否使用 TypeScript?建议Yes。
   • 是否使用 ESLint?建议Yes。
   • 是否使用 Tailwind CSS?可选，根据项目需要。
   • 是否使用src/目录?可选。
   • 是否使用 App Router?必须选择Yes。PPR 深度依赖于 App Router 架构。
   • 是否自定义默认的导入别名?通常选No。

2. 启用实验性 PPR 标志：在项目根目录的next.config.js(或next.config.mjs) 文件中，你需要显式启用 PPR。

   // next.config.js /** @type {import('next').NextConfig} */ const nextConfig = { experimental: { ppr: true, // 启用部分预渲染 }, }; module.exports = nextConfig;

   重要提醒：ppr: true是一个实验性标志。这意味着 API 和行为在未来的稳定版中可能发生变化。请密切关注 Next.js 官方博客和发布说明。

3. 确保使用 React 18+ 和 Suspense：PPR 依赖于 React 的并发特性（Concurrent Features）和Suspense组件来实现流式传输。你的react和react-dom版本必须支持。

4. 定义静态与动态：generateStaticParams与dynamic

在 PPR 模型中，清晰地定义哪些是静态的、哪些是动态的，是开发者的首要工作。Next.js 提供了直观的 API 来实现这种声明。

4.1 静态路由生成 (generateStaticParams)

对于使用动态路由的页面（例如app/blog/[slug]/page.js），generateStaticParams函数用于在构建时确定哪些路径应该生成静态骨架。

// app/blog/[slug]/page.js // 这个函数在构建时运行，用于生成静态路径 export async function generateStaticParams() { // 假设从 CMS 或数据库获取所有博客文章的 slug 列表 const posts = await fetch('https://api.example.com/posts').then((res) => res.json()); // 返回一个对象数组，每个对象对应一个动态路由参数 return posts.map((post) => ({ slug: post.slug, // 必须与 [slug] 文件夹名匹配 })); }

关键点：generateStaticParams定义了哪些路由有资格进行预渲染（生成静态骨架）。即使路径是动态的（如/blog/my-post），只要它的参数（slug: 'my-post'）在generateStaticParams的返回列表中，Next.js 就会尝试为它预渲染静态部分。

4.2 组件级动态性声明 (dynamic)

这是 PPR 的灵魂。你可以在组件级别，通过dynamic函数或React.cache等 API，来声明一个组件的数据获取是动态的、需要流式传输的。在 Next.js App Router 中，更常见的模式是使用async组件配合Suspense。

• 静态组件（默认）：一个普通的 React 组件或async组件，其数据在构建时或首次生成静态骨架时获取并固化。
• 动态组件：被包裹在<Suspense>边界内的async组件。其数据获取会被推迟，并在准备好后流式传输。

// app/blog/[slug]/page.js import { Suspense } from 'react'; import PostContent from '@/components/PostContent'; // 假设是静态组件 import CommentsList from '@/components/CommentsList'; // 动态组件 import RecommendedPosts from '@/components/RecommendedPosts'; // 另一个动态组件 export default async function BlogPostPage({ params }) { const { slug } = params; // 这里可以获取静态数据，例如文章内容 const postData = await getPostData(slug); // 这个调用会阻塞静态骨架生成吗？不会，因为它不在 Suspense 内，但它是 async 的。在 PPR 上下文中，我们需要理解：页面组件本身的 `async` 和数据获取，决定了整个页面是静态生成还是动态渲染。对于 PPR，我们更倾向于将动态部分剥离到子组件中。 return ( <article> <h1>{postData.title}</h1> {/* 静态部分：文章内容 */} <PostContent content={postData.content} /> {/* 动态部分：评论列表 - 使用 Suspense 包裹 */} <section> <h2>评论</h2> <Suspense fallback={<div>正在加载评论...</div>}> {/* CommentsList 是一个 async 组件，内部有数据获取 */} <CommentsList postId={postData.id} /> </Suspense> </section> {/* 动态部分：相关推荐 */} <section> <h2>你可能也喜欢</h2> <Suspense fallback={<div>正在加载推荐...</div>}> <RecommendedPosts currentPostId={postData.id} /> </Suspense> </section> </article> ); } // 模拟获取静态文章数据 async function getPostData(slug) { // 这里应该是从数据库或 CMS 获取 return { id: '123', slug: slug, title: `文章标题：${slug}`, content: '这里是文章正文内容...', }; }

// components/CommentsList.js // 这是一个动态组件 export default async function CommentsList({ postId }) { // 这个 fetch 会在页面请求时执行，数据是动态的 // 注意：为了演示，这里使用了 `no-store` 禁用缓存。在实际 PPR 中，即使不使用 `no-store`，因为组件被 Suspense 包裹，其获取也会被推迟。 const comments = await fetch(`https://api.example.com/posts/${postId}/comments`, { cache: 'no-store', }).then((res) => res.json()); if (comments.length === 0) { return <p>暂无评论</p>; } return ( <ul> {comments.map((comment) => ( <li key={comment.id}> <strong>{comment.author}</strong>: {comment.text} </li> ))} </ul> ); }

工作原理：当访问/blog/my-post时：

1. Next.js 识别到该路径由generateStaticParams预定义，因此决定为其生成一个静态骨架。
2. 在生成静态骨架时，它会执行BlogPostPage组件。遇到<Suspense>边界时，它不会等待内部的CommentsList和RecommendedPosts的数据获取完成。
3. 它先获取getPostData(slug)（因为它在 Suspense 外部），并用其数据渲染出<h1>和<PostContent>的静态 HTML。
4. 对于<Suspense>区域，它生成一个特殊的占位符（fallback内容，即“正在加载评论...”），这就是“流式洞”。
5. 这个包含静态内容和动态占位符的 HTML 骨架被迅速发送给浏览器。
6. 在服务器端，CommentsList和RecommendedPosts的数据获取并行进行。
7. 一旦CommentsList的数据获取完成，服务器就将渲染好的<ul>...</ul>HTML 片段，通过之前建立的连接流式传输到浏览器，替换掉对应的占位符。RecommendedPosts同理。

5. 完整示例：构建一个混合渲染的博客首页

让我们通过一个更完整的例子，将上述概念串联起来。我们将构建一个博客首页 (/app/page.js)，它包含：

1. 静态的站点标题和导航栏。
2. 静态的文章摘要列表（从 CMS 在构建时获取）。
3. 动态的“当前在线用户数”组件。
4. 动态的“天气信息”组件。

项目结构：

my-ppr-app/ ├── app/ │ ├── layout.js │ ├── page.js # 博客首页 │ ├── blog/ │ │ └── [slug]/ │ │ └── page.js # 博客文章页（参考上文） │ └── globals.css ├── components/ │ ├── Header.js │ ├── PostList.js # 静态文章列表 │ ├── OnlineUsers.js # 动态在线用户 │ └── WeatherWidget.js # 动态天气组件 ├── next.config.js └── package.json

步骤 1：布局与静态头部 (app/layout.js,components/Header.js)

// app/layout.js import { Inter } from 'next/font/google'; import './globals.css'; import Header from '@/components/Header'; const inter = Inter({ subsets: ['latin'] }); export const metadata = { title: '我的 PPR 博客', description: '体验部分预渲染的魅力', }; export default function RootLayout({ children }) { return ( <html lang="zh-CN"> <body className={inter.className}> <Header /> <main className="container mx-auto p-4">{children}</main> </body> </html> ); }

// components/Header.js export default function Header() { return ( <header className="bg-gray-800 text-white p-4"> <div className="container mx-auto"> <h1 className="text-2xl font-bold">我的 PPR 博客</h1> <nav className="mt-2"> <a href="/" className="mr-4 hover:underline">首页</a> <a href="/about" className="hover:underline">关于</a> </nav> </div> </header> ); }

步骤 2：首页主体 - 混合静态与动态 (app/page.js)

// app/page.js import { Suspense } from 'react'; import PostList from '@/components/PostList'; // 静态组件 import OnlineUsers from '@/components/OnlineUsers'; // 动态组件 import WeatherWidget from '@/components/WeatherWidget'; // 动态组件 // 这是一个异步页面组件，但它的数据获取决定了页面的初始渲染模式。 // 如果这个 fetch 是静态的（无缓存策略或 `force-static`），且没有动态函数，页面可能静态生成。 // 为了演示 PPR，我们假设文章列表数据在构建时获取。 async function getStaticPostList() { // 模拟从 CMS 获取数据，构建时运行 const res = await fetch('https://api.example.com/posts?_limit=5', { // 在构建时获取，可以缓存。在生产中，可能需要结合 `revalidate` 进行增量静态再生(ISR)。 next: { revalidate: 3600 }, // 每1小时重新验证并可能重新生成 }); if (!res.ok) throw new Error('Failed to fetch posts'); return res.json(); } export default async function HomePage() { // 获取静态文章列表数据。这个调用在生成静态骨架时执行。 const posts = await getStaticPostList(); return ( <div> <h2 className="text-3xl font-bold mb-6">最新文章</h2> {/* 静态部分：文章列表 */} <PostList posts={posts} /> <div className="grid grid-cols-1 md:grid-cols-2 gap-6 mt-12"> {/* 动态部分：在线用户 - 流式加载 */} <section className="bg-blue-50 p-4 rounded-lg"> <h3 className="text-xl font-semibold mb-2">当前在线</h3> <Suspense fallback={<div className="text-gray-500">正在查询在线人数...</div>}> <OnlineUsers /> </Suspense> </section> {/* 动态部分：天气信息 - 流式加载 */} <section className="bg-green-50 p-4 rounded-lg"> <h3 className="text-xl font-semibold mb-2">当地天气</h3> <Suspense fallback={<div className="text-gray-500">正在获取天气...</div>}> <WeatherWidget city="Beijing" /> </Suspense> </section> </div> </div> ); }

步骤 3：实现静态与动态子组件

// components/PostList.js - 静态组件 export default function PostList({ posts }) { return ( <ul className="space-y-4"> {posts.map((post) => ( <li key={post.id} className="border-b pb-4"> <h3 className="text-xl font-semibold"> <a href={`/blog/${post.slug}`} className="hover:text-blue-600">{post.title}</a> </h3> <p className="text-gray-600 mt-1">{post.excerpt}</p> <time className="text-sm text-gray-400">{new Date(post.publishedAt).toLocaleDateString()}</time> </li> ))} </ul> ); }

// components/OnlineUsers.js - 动态组件 export default async function OnlineUsers() { // 模拟一个动态 API 调用，获取实时在线用户数 // 使用 `no-store` 确保每次请求都获取最新数据 await new Promise(resolve => setTimeout(resolve, 1000)); // 模拟1秒延迟 const onlineCount = Math.floor(Math.random() * 100) + 50; // 模拟随机数据 return ( <div> <p className="text-2xl font-bold">{onlineCount}</p> <p className="text-sm text-gray-600">位用户正在浏览</p> </div> ); }

// components/WeatherWidget.js - 动态组件 export default async function WeatherWidget({ city }) { // 模拟调用天气 API，这里使用一个公开的模拟 API // 注意：实际项目请替换为真实的、有权限的天气 API const res = await fetch(`https://api.weatherapi.com/v1/current.json?key=YOUR_API_KEY&q=${city}&aqi=no`, { cache: 'no-store', // 动态数据，不缓存 }); // 由于是示例，我们模拟数据以避免需要真实 API 密钥 // const data = await res.json(); // const { temp_c, condition } = data.current; // 模拟数据 await new Promise(resolve => setTimeout(resolve, 1500)); // 模拟1.5秒延迟 const temp_c = Math.floor(Math.random() * 15) + 10; // 10-24度 const condition = { text: '晴朗' }; return ( <div className="flex items-center"> <div className="text-4xl font-bold mr-4">{temp_c}°C</div> <div> <p className="font-medium">{condition.text}</p> <p className="text-sm text-gray-600">{city}</p> </div> </div> ); }

6. 运行、验证与效果对比

运行项目：

npm run dev # 或 yarn dev # 或 pnpm dev

访问http://localhost:3000。

验证 PPR 效果：

1. 观察页面加载：你会立即看到博客标题、导航栏和“最新文章”列表。而“当前在线”和“当地天气”区域会先显示fallback内容（“正在查询...”）。
2. 约1-1.5秒后，这两个动态区域会先后填充真实数据。关键点在于：动态数据的加载没有阻塞静态内容的渲染和显示。
3. 使用浏览器开发者工具：
   • 打开Network标签页，筛选Doc类型。
   • 刷新页面，观察对根文档 (/) 的请求。
   • 你会看到响应是流式传输的。静态 HTML 先到达，然后可以看到后续的多个data:块，这些就是动态片段。
   • 在Sources或Elements面板中，你可以看到初始 HTML 中包含<!--$?-->和<!--/$-->这样的注释标记，这就是 React Suspense 边界和流式占位符。

与传统 SSR 对比：

• 传统 SSR：浏览器需要等待服务器获取文章列表、在线用户、天气信息所有数据并完成渲染后，才能收到完整的 HTML。TTFB（到首字节时间）会等于最慢的那个数据请求。
• PPR：浏览器几乎立刻收到包含文章列表的 HTML 骨架（TTFB 极短），并开始渲染。在线用户和天气数据在后台加载，并以流的方式更新页面。

与纯 SSG + 客户端获取对比：

• SSG + Client Fetch：静态 HTML 包含文章列表，但在线用户和天气区域初始是空的或只有 Loading 骨架屏。需要等待 JavaScript 加载、解析、执行，然后发起 fetch 请求，最后渲染。这可能导致布局偏移和更长的可交互时间。
• PPR：动态内容由服务器直接流式传输为 HTML，无需等待客户端 JavaScript 来发起数据请求和渲染。水合（Hydration）仍然需要，但内容的展示更早、更稳定。

7. 常见问题、排查思路与局限性

尽管 PPR 前景光明，但在当前实验阶段，你可能会遇到一些问题。

问题现象	可能原因	排查方式	解决方案
PPR 未生效，整个页面都在等待动态数据	1.next.config.js中未启用experimental.ppr: true。 2. 动态组件没有被<Suspense>边界包裹。 3. 页面组件本身的数据获取（如HomePage中的getStaticPostList）太慢或阻塞。	1. 检查next.config.js配置。 2. 确认所有需要流式传输的async组件都在<Suspense>内。 3. 使用console.log或调试工具，确认静态数据获取是否在预期时间内完成。	1. 确保配置正确。 2. 为所有动态async组件添加<Suspense>父级。 3. 优化静态数据获取逻辑，或考虑将其移至客户端（如果不影响 SEO）。
动态组件流式传输失败，显示错误或空白	1. 动态组件内部fetch或数据获取出错。 2. 动态组件抛出了未被捕获的异常。 3. 网络不稳定导致流中断。	1. 检查浏览器控制台和服务器端日志中的错误信息。 2. 在动态组件内部添加try...catch进行错误处理。 3. 使用error.js边界文件来捕获组件级错误并显示降级 UI。	1. 确保 API 端点可用且返回正确格式。 2. 在动态组件中实现健壮的错误处理。 3. 为<Suspense>的fallback提供友好的加载状态，为错误提供降级 UI。
构建失败或开发服务器报错	1. Next.js 或 React 版本不兼容。 2. PPR 实验性 API 变更。 3. 在generateStaticParams中使用了动态函数（如cookies(),headers()）。	1. 检查package.json中next、react、react-dom的版本。 2. 查阅 Next.js Canary 版本的更新日志。 3. 确保generateStaticParams是纯静态的。	1. 升级到支持的版本。 2. 关注 Next.js GitHub 仓库和发布说明，调整代码以适应 API 变化。 3. 将依赖动态函数的逻辑移出generateStaticParams。
SEO 担忧：流式内容能否被爬虫抓取？	对搜索引擎爬虫行为的疑虑。	测试工具（如 Google Rich Results Test）或查看服务器日志中爬虫的 User-Agent。	Next.js 的 PPR 实现会考虑 SEO。对于支持流式响应的爬虫（如 Googlebot），它可能会等待流式内容完成。为关键动态内容考虑使用loading.js提供静态 fallback，或确保动态内容对 SEO 非关键。

当前局限性：

• 实验性特性：API 可能发生变化，不适合用于对稳定性要求极高的生产环境。
• 复杂度转移：从“优化单个请求”变为“管理多个流式片段的状态和错误”，对错误处理和状态管理提出了新要求。
• 调试难度：流式传输使得传统的“查看页面源代码”变得不那么直观，需要借助开发者工具。
• 缓存策略：静态骨架和动态片段的缓存策略需要仔细设计，特别是对于个性化内容。

8. 最佳实践与工程建议

在项目中应用 PPR 时，遵循以下建议可以事半功倍：

1. 精准划分 Suspense 边界：不要用一个巨大的<Suspense>包裹整个页面。应该为每个独立的动态数据区块创建精细的 Suspense 边界。这样，一个区块的加载失败或延迟不会影响其他区块的显示。

   // 推荐：精细划分 <div> <Suspense fallback={<UserPanelSkeleton />}> <UserPanel /> </Suspense> <Suspense fallback={<NotificationSkeleton />}> <NotificationList /> </Suspense> </div>

2. 设计有意义的 Fallback UI：fallback属性不仅是放一个Loading...文字。应该设计与最终组件形状和大小相似的骨架屏（Skeleton Screen），以避免布局偏移，提升感知性能。

3. 静态化所有可能的内容：PPR 的优势在于最大化静态部分。仔细审查页面，将任何可以在构建时或首次访问时确定的内容标记为静态。即使是“最新文章”这种看似动态的内容，如果更新频率不高，也可以结合 ISR（增量静态再生）来实现准静态。

4. 动态数据的错误处理：流式传输中，一个动态片段的失败不应导致整个页面崩溃。务必在每个async组件中使用try...catch，并利用 Next.js 的error.js文件机制来提供组件级的错误恢复界面。

5. 关注数据获取策略：

   • 静态数据：使用fetch时，利用next: { revalidate: 60 }进行 ISR，或在generateStaticParams中预生成。
   • 动态数据：在 Suspense 内部的组件中获取，使用cache: 'no-store'或revalidate: 0。
   • 个性化数据：需要根据用户会话动态获取的数据，必须放在动态组件中，并且要注意缓存和隐私问题。

6. 性能监控与测量：PPR 改变了性能指标的意义。除了传统的 FCP、LCP、TTI，还需要关注：

   • 静态部分渲染时间。
   • 各个动态片段的加载时间。
   • 流式传输的完成时间。 使用像 Web Vitals 这样的工具进行监控。

7. 渐进式采用：对于已有项目，不要试图一次性重写所有页面。可以从一个独立的、功能相对简单的页面（如关于页、营销落地页）开始试验 PPR，积累经验后再逐步应用到核心页面。

PPR 代表了前端渲染范式的一次重要演进，它试图在静态站点的速度与服务端渲染的灵活性之间找到最佳平衡点。它要求开发者以“部分”和“流”的思维来构建页面，将内容按稳定性进行分层。虽然目前仍处于实验阶段，但其理念无疑是正确的方向。

对于开发者而言，现在正是学习和实验 PPR 的好时机。通过理解其原理，掌握在 Next.js 中的基本用法，并预见到其潜在的复杂性和最佳实践，你就能在未来这项技术成熟并稳定时，快速将其应用到生产环境中，为用户带来瞬开网页且内容实时的新体验。建议将本文中的示例代码作为起点，亲手搭建一个 demo 项目，感受静态骨架瞬间呈现、动态数据随后流式注入的流畅过程，这比阅读任何文章都更能加深理解。