当前位置：首页 > news >正文

Next.js 客户端渲染 (CSR) 与 Next.js 的结合使用

news 2025/9/11 8:07:21

客户端渲染 (CSR) 与 Next.js 的结合使用

作者：码力无边

在过去的几篇文章中，我们深入探索了 Next.js 强大的服务端渲染世界，掌握了 SSG、SSR 和 ISR 这三把利器。它们的核心优势在于预渲染——在服务器上提前生成 HTML，从而实现卓越的 SEO 和首屏加载性能。

这可能会让一些来自传统 React (如 Create React App) 开发背景的同学产生一个疑问：难道在 Next.js 中，我们就告别了那种熟悉的、在组件加载后用 useEffect 和 fetch 来获取数据的客户端渲染 (Client-Side Rendering, CSR) 模式了吗？

答案是否定的。CSR 不仅没有被抛弃，反而在 Next.js 应用中扮演着至关重要的、不可或缺的角色。一个成熟、复杂的 Next.js 应用，往往是多种渲染策略的混合体。本文将深入探讨 CSR 的本质，以及何时、何地、以及如何优雅地在 Next.js 中使用它。

什么是客户端渲染 (CSR)？

让我们先快速回顾一下 CSR 的工作流程，以便更好地理解它与预渲染的区别。

浏览器请求：浏览器向服务器请求一个页面。
服务器响应：服务器返回一个近乎空白的 HTML “骨架” 文件，以及一个或多个 JavaScript 包。
浏览器下载与执行：浏览器下载这些 JavaScript 文件。
React 启动：JavaScript 执行，React 开始在客户端启动。
数据获取：React 组件（例如，通过 useEffect 钩子）向 API 发送数据请求。
渲染内容：数据返回后，React 使用这些数据来渲染 UI，并将其插入到 DOM 中。用户此时才能看到最终的页面内容。

核心特点：页面的主要内容是在用户的浏览器中通过 JavaScript 生成的。

优点：

页面切换快：一旦应用加载完毕，后续的页面内导航（客户端路由）通常非常快，因为它只请求数据，而不是整个 HTML 页面。
服务器负载低：服务器只负责提供静态文件和 API，渲染的计算压力被分散到了成千上万的客户端。

缺点（这也是 Next.js 主要解决的问题）：

SEO 不友好：搜索引擎爬虫可能无法正确执行 JavaScript，导致抓取不到页面内容。
首屏加载慢 (FCP/LCP)：用户在看到内容前，需要经历下载、解析、执行 JavaScript 以及数据请求的完整过程，会有一段明显的“白屏”或“加载中”的时间。

在 Next.js 中，CSR 的用武之地

既然预渲染这么好，为什么我们还需要 CSR？因为预渲染主要关注的是页面的初始加载。一旦页面“活”过来了（这个过程称为 hydration），它就变成了一个标准的 React 应用，而许多动态交互和非关键性内容的加载，恰恰是 CSR 的最佳舞台。

以下是几个在 Next.js 中必须或推荐使用 CSR 的典型场景：

1. 高度动态且个性化的组件级数据

场景：想象一个复杂的仪表盘 (Dashboard) 页面。这个页面的主体结构（导航栏、侧边栏）可能是通过 SSR (getServerSideProps) 预渲染的，以确保用户能快速看到基础布局。但是，仪表盘内部有多个独立的小组件 (Widgets)，比如：

一个实时显示在线用户数的图表。
一个展示用户最新活动的时间线。
一个需要频繁轮询的通知中心。

这些组件的数据有以下特点：

高度个性化：完全依赖于当前登录的用户。
实时性要求高：需要频繁更新，甚至使用 WebSocket。
非关键性：它们的加载与否，不影响页面的主体可读性。

为什么不适合预渲染？ 如果把所有这些小组件的数据获取逻辑都塞进 getServerSideProps，会导致整个页面的 TTFB (Time to First Byte) 变得极慢。用户必须等待所有数据都准备好，才能看到页面。

最佳实践 (CSR)：

页面主体使用 getServerSideProps 或 getStaticProps 进行预渲染。
每个动态小组件内部使用自己的 CSR 逻辑（如 SWR 或 React Query）来独立获取和管理数据。

代码示例 (使用 SWR)

SWR 是由 Vercel 团队（Next.js 的创造者）推出的一个强大的客户端数据获取库，它提供了缓存、自动重新验证等强大功能，与 Next.js 配合得天衣无缝。

// pages/dashboard.tsx (页面)
export const getServerSideProps = async (context) => {// ... 检查用户登录状态，获取基础用户信息 ...return { props: { user } };
};export default function DashboardPage({ user }) {return (<div><h1>欢迎, {user.name}!</h1><main><OnlineUsersWidget /> {/* CSR 组件 */}<ActivityFeedWidget /> {/* CSR 组件 */}</main></div>);
}

// components/OnlineUsersWidget.tsx (组件)
import useSWR from 'swr';// 定义一个 fetcher 函数
const fetcher = (url: string) => fetch(url).then((res) => res.json());export function OnlineUsersWidget() {const { data, error } = useSWR('/api/online-users', fetcher, {refreshInterval: 5000, // 每 5 秒自动重新获取});if (error) return <div>加载失败</div>;if (!data) return <div>加载中...</div>; // 显示加载状态return <div>当前在线人数: {data.count}</div>;
}

在这个例子中，用户会立即看到欢迎语，而“在线人数”则会在稍后异步加载并显示，互不阻塞。

2. 用户输入驱动的数据获取

场景：一个搜索框。用户输入关键词后，需要根据输入动态地获取搜索建议。

这个过程完全由客户端的用户行为触发，不可能在服务器上预渲染。这正是 CSR 的经典应用场景。

3. SEO 不重要，且数据私有的页面

场景：一个复杂的“账户设置”页面，包含多个标签页和表单。

SEO 无关：搜索引擎不需要也无法索引这个页面。
数据私有：所有数据都与特定用户相关。
交互复杂：用户在不同标签页之间切换，只需要更新部分数据。

在这种情况下，即使整个页面都可以通过 SSR 加载，采用 CSR 模式也可能带来更好的用户体验。可以先快速加载一个页面“壳”，然后根据用户的点击行为，异步加载各个部分的数据，使得交互响应更迅速。

渲染策略的混合与选择

一个成熟的 Next.js 开发者，应该像一个厨师一样，根据“菜品”（页面/组件）的特点，灵活选用不同的“烹饪方法”（渲染策略）。

策略	何时使用	示例
SSG	页面内容可预知，对所有用户相同，SEO 关键。	博客文章、文档、营销首页。
ISR	同 SSG，但内容需要定期自动更新。	新闻网站首页、电商产品列表。
SSR	页面内容依赖于请求信息（用户身份），SEO 关键。	用户个人资料页、订单详情页。
CSR	组件级数据、用户交互驱动、SEO 不重要、需要实时更新。	仪表盘小组件、搜索建议、账户设置。