`Next.js` 是一个基于 `React` 的全栈 Web 开发框架，它支持多种渲染模式，其中 `Server-Side Rendering` **（SSR，服务器端渲染）** 是一种核心功能。SSR 允许在服务器上动态生成 `HTML` 页面，并在每个请求时发送给客户端，从而实现动态内容渲染、更好的 **SEO** 和**初始加载性能**。`Next.js` 根据路由器类型（Pages Router 和 App Router）对 SSR 的实现有所不同。下面我将详细介绍 SSR 的概念、实现方式、优缺点、与其他渲染模式的比较、代码示例以及最佳实践。内容基于 `Next.js` 最新版本（截至 2026 年初，版本 16.1.2）的官方文档。 ## 1. SSR 的基本概念 **SSR** 指的是在服务器上为每个用户请求生成完整的 `HTML` 页面，然后发送到浏览器。相比客户端渲染（CSR），SSR 可以预先渲染内容，提高首次内容绘制（FCP）的速度，并支持搜索引擎优化（SEO）。在 `Next.js` 中，SSR 常用于需要频繁更新数据的页面，如用户个性化内容或实时 API 数据。 - **工作原理**：当浏览器发出请求时，服务器执行渲染逻辑（包括数据获取），生成 `HTML` 并返回。浏览器收到后，可以立即显示内容，同时加载 `JavaScript` 以实现交互性（hydration）。 - **适用场景**：数据频繁变化、需要服务器端安全访问（如 API 密钥）、或对 SEO 要求高的页面。 ## 2. Pages Router 中的 SSR `Pages Router` 是 `Next.js` 的传统路由系统（位于 /pages 目录），SSR 通过 `getServerSideProps` 函数实现，也称为“动态渲染”。 - **实现方法**： - 在页面文件中导出异步函数 `getServerSideProps`，该函数在每个请求时服务器执行，用于获取数据并作为 props 传递给页面组件。 - 函数返回一个对象 `{ props: { ... } }`，其中 props 是序列化的数据。 ```js // pages/index.js export default function Home({ data }) { return (

服务器端渲染示例

数据: {data.message}

); } // 每个请求时执行 export async function getServerSideProps() { const res = await fetch("https://api.example.com/data"); const data = await res.json(); return { props: { data } }; } ``` - **优缺点**： - **优点**：数据实时更新，确保页面总是最新；支持动态路由和查询参数。 - **缺点**：每个请求都需服务器渲染，可能增加服务器负载和响应时间；不适合静态内容（会降低性能）。 | 渲染模式 | 描述 | 执行时机 | 适用场景 | 与 SSR 的区别 | | ------------------------------------- | ----------------------- | ----------------- | -------------- | ------------------------------------------------------- | | SSR (Server-Side Rendering) | 每个请求服务器生成 HTML | 每个请求 | 动态数据、SEO | - | | SSG (Static Site Generation) | 构建时生成静态 HTML | 构建时 | 静态内容、博客 | 构建后内容固定，不动态更新；使用 `getStaticProps` | | CSR (Client-Side Rendering) | 浏览器端渲染 | 客户端加载后 | 高度交互应用 | 无服务器预渲染，初始加载慢；使用 `useEffect` 或库如 SWR | | ISR (Incremental Static Regeneration) | 构建时生成 + 按需再生 | 构建时 + 再生间隔 | 半动态内容 | 结合 SSG 和 SSR，支持缓存再生 | - **最佳实践**： - 只在需要动态数据的页面使用 SSR，避免过度使用以减轻服务器压力。 - 结合缓存（如 Vercel 的边缘缓存）优化性能。 - 如果数据不频繁变化，优先考虑 SSG 或 ISR。 ## 3. App Router 中的 SSR（基于 Server Components） App Router 是 `Next.js` 的新一代路由系统（位于 `/app` 目录），引入了 React Server Components（RSC），默认所有布局和页面都是 Server Components，从而实现细粒度的 SSR。这使得渲染更高效，支持 **流式传输（streaming）** 和部分缓存。 - **实现方法**： - **服务器端**：组件在服务器上渲染成 RSC Payload，包括 Server Components 的输出和对 Client Components 的引用。同时，生成初始 HTML 用于快速非交互预览。 - **客户端首次加载**：服务器发送 HTML（快速显示）、RSC Payload（协调 Server 和 Client 组件树）和 JavaScript（用于 hydration，即附加事件处理器，使页面交互）。 - **后续导航**：RSC Payload 被预取和缓存，在客户端渲染 Client Components，无需服务器 HTML。 - **支持异步数据获取**：组件可以是 async 函数，直接 await 数据。 - **流式渲染**：使用 Suspense 边界逐步发送内容，避免阻塞整个页面。 - **代码示例**： ```tsx // app/page.tsx import LikeButton from "./ui/like-button"; // Client Component // 在服务器上获取数据 async function getPost(id: string) { const res = await fetch(`https://api.example.com/post/${id}`); return res.json(); } export default async function Page({ params, }: { params: Promise<{ id: string }>; }) { const { id } = await params; const post = await getPost(id); return (

{post.title}

{/* 传递 props 到 Client Component */}

); } ``` ```tsx // app/ui/like-button.tsx (Client Component) "use client"; import { useState } from "react"; export default function LikeButton({ likes }: { likes: number }) { const [count, setCount] = useState(likes); return ; } ``` - **优缺点**： - **优点**：减少客户端 JavaScript 体积；支持流式渲染，提高 FCP；安全处理敏感数据（如 API 密钥）；易于与 Client Components 组合。 - **缺点**：Server Components 不支持状态、事件或浏览器 API（如 useState、localStorage）；需确保 props 可序列化；上下文（Context）需包裹在 Client Components 中。 > 与 Pages Router 相比，App Router 的 SSR 更现代，支持 React 18+ 特性如 Suspense 和 streaming。 - **最佳实践**： - 最小化 `'use client'` 的使用，只在需要交互的组件中应用，以优化包大小。 - 使用 Server Components 处理数据获取和静态 UI，Client Components 处理交互。 - 通过 props 传递数据，确保可序列化；使用 `server-only` 包防止服务器代码泄露到客户端。 - 对于上下文或第三方库，包裹在 Client Components 中。 - 利用 streaming（如 use hook）处理慢速数据，提高用户体验。 - 在布局中深层放置 Client Components，以保持上层 Server Components 的静态性。 - 通过 Suspense 实现流式渲染：`}>`。 ## 4. 何时选择 Pages Router 或 App Router 中的 SSR - 如果项目已使用 Pages Router，且不需要 React Server Components 的高级特性，继续使用 `getServerSideProps。` - 对于新项目或迁移，推荐 App Router 的 Server Components，因为它更灵活、性能更好，并支持未来 React 更新。 > SSR 适合动态页面，但如果内容静态，优先 SSG/ISR 以减少服务器成本。 ## 5. 触发 SSR **App Router 中最常见的几种触发 SSR 的方式（推荐优先级从高到低）** | 触发方式 | 说明 | 什么时候用 | 代码示例 | |-----------------------------------|----------------------------------------------------------------------|------------------------------------------|--------------------------------------------------------------------------| | **使用动态数据获取（无缓存）** | 最自然、最常用的方式。只要组件里用了不缓存的 `fetch` 或其他 await 操作，Next.js 自动走 SSR | 需要实时/个性化数据（如用户数据、搜索结果） | `const data = await fetch(url).then(r => r.json())` 或 `await db.query()` | | **使用了 cookies() / headers()** | 读取 Cookie 或请求头 → 必须每个请求都执行 → 强制动态渲染/SSR | 认证、A/B 测试、地理位置、User-Agent 等 | `import { cookies, headers } from 'next/headers'` | | **export const dynamic = 'force-dynamic'`** | 强制整个路由段（segment）走动态渲染（SSR），忽略任何缓存 | 需要完全禁用缓存的页面 | 文件顶部写 `export const dynamic = 'force-dynamic';` | | **使用了 searchParams** | 页面组件接收 `searchParams` 参数 → 自动动态渲染 | 有查询参数的页面（如分页、过滤） | `export default function Page({ searchParams }) { ... }` | | **未设置任何缓存，且有 await** | 只要组件是 async + 有 await 数据获取，默认就是动态渲染（SSR） | 大多数动态页面 | `export default async function Page() { const data = await ... }` | ### 5.1 最常见 - 直接 await 数据（自动 SSR） ```tsx // app/dashboard/page.tsx export default async function Dashboard() { const user = await getCurrentUser(); // ← 这里 await → 触发 SSR const posts = await db.posts.findMany({ where: { authorId: user.id } }); return (

Welcome, {user.name}

{/* ... */}

); } ``` → 自动 **SSR**，因为有 await 且没有强制缓存。 ### 5.2 读取 cookies 或 headers（强制 SSR） ```tsx // app/profile/page.tsx import { cookies, headers } from "next/headers"; export default async function Profile() { const cookieStore = cookies(); const token = cookieStore.get("auth_token")?.value; const userAgent = headers().get("user-agent"); // ← 读取 headers → 强制 SSR const user = await verifyToken(token); return

Hello {user.name}

; } ``` ### 5.3 强制动态渲染（最强力方式） ```tsx // app/admin/page.tsx export const dynamic = "force-dynamic"; // ← 整个页面强制 SSR，无缓存 export default async function AdminDashboard() { // 即使你这里用了缓存 fetch，也会被忽略 const stats = await fetch("/api/stats", { cache: "force-cache" }).then((r) => r.json() ); return

Admin Stats: {stats.value}

; } ``` ### 5.4 带 searchParams（自动 SSR） ```tsx // app/search/page.tsx export default async function SearchPage({ searchParams, }: { searchParams: Promise<{ q?: string; page?: string }>; }) { const params = await searchParams; const query = params.q || ""; const results = await searchPosts(query); // ← 动态查询 → SSR return

Results for "{query}"

; } ``` ## 6. SSR 优缺点 ### 6.1 优点 - **SEO 和性能**：搜索引擎易爬取完整 HTML；更快 FCP（First Contentful Paint）。 - **数据安全**：服务器上处理秘密（如 API 密钥），不暴露给客户端。 - **动态性**：实时数据、个性化（如基于 cookie 或 IP）。 - **流式渲染**：逐步加载，提高感知速度。 - **减少客户端负担**：最小化浏览器 JS，适合低端设备。 ### 6.2 缺点 - **服务器负载**：每个请求渲染，增加延迟和成本（尤其高流量时）。 - **无默认缓存**：需手动配置（如 Cache-Control），否则性能差。 - **TTI（Time to Interactive）**：hydration 后才交互，可能稍慢。 - **不适合静态内容**：浪费资源；用 SSG 更好。 ## 7. 快速判断当前页面是否走 SSR 的方法 ### 7.1 开发模式 - 运行 next dev - 访问页面，看终端日志： - `λ (Server)` → SSR / 动态渲染 - `○ (Static)` → 静态渲染（SSG） ### 7.2 生产模式 - 运行 `next build` - 看 `.next` 目录下是否有该页面的 `.html` 文件（有 → 可能静态；无或很少 → 动态/SSR） ## 8. 总结想让页面走 SSR？记住这三点任意一点满足即可： 1. 在 Server Component 里直接 await 获取数据（不加缓存） 2. 用 cookies()、headers() 或 searchParams 3. 文件顶部写 export const dynamic = 'force-dynamic'; > 最推荐的方式是第 1 种：直接在组件里 await 数据，这是 Next.js App Router 设计的核心哲学——“让数据获取决定渲染模式”。

相关文章

静态站点生成（SSG）

Next.js中的cache（四种缓存机制）

相关文章

静态站点生成（SSG）

Next.js中的cache（四种缓存机制）