React 服务端渲染

约 714 字大约 2 分钟

reactssrrendering

2026年04月08日

React SSR 的目标不是“把前端搬到服务端”，而是在首屏性能、SEO、分享卡片和弱网体验之间找到更好的平衡。

常见渲染模式

CSR：浏览器拿到 JS 后再渲染
SSR：服务端先输出 HTML，再由客户端 hydration
SSG：构建时生成静态 HTML
ISR：静态页按策略增量再生成
预渲染：先产出壳页面，再补齐动态内容

为什么需要 SSR

适合 SSR 的场景：

SEO 敏感页面
首屏内容价值高
社交分享需要完整元信息
弱网设备首屏体验要求高

不一定需要 SSR 的场景：

强交互后台系统
登录后业务页面
主要依赖客户端实时能力的应用

React SSR 的核心流程

服务端根据 URL 匹配页面
拉取当前页面需要的数据
生成 HTML 返回给浏览器
浏览器加载 JS 后执行 hydration
页面变成可交互应用

在 React 18 里，流式渲染与 Suspense 让 SSR 的体验更细粒度。

路由与数据在 SSR 中的组织

SSR 里要同时处理三类一致性：

路由一致：服务端和客户端匹配同一路由树
数据一致：首屏数据在两端一致，避免 hydration mismatch
状态一致：Redux 或其他 store 需要可序列化、可注水

常见做法：

服务端先收集页面数据
把首屏数据序列化注入 HTML
客户端用同一份初始数据初始化 store

SEO 与元信息

SSR 的优势不只是 HTML 提前返回，还包括页面头信息可服务端输出：

title
meta description
Open Graph / Twitter Card
结构化数据

如果页面内容依赖客户端二次请求，SEO 收益会打折。

预渲染与缓存

很多项目并不需要“所有页面都 SSR”。

更现实的策略是：

营销页、博客页做 SSG / ISR
列表页按缓存策略 SSR
用户后台保留 CSR

核心不在技术名词，而在渲染策略和业务价值匹配。

Koa + Next.js 的实践意义

知识架构里提到的 Koa2 + Next.js，本质是在理解：

Node 服务端如何接管请求
React 页面如何参与首屏输出
服务端和客户端如何共享路由、数据和状态

现代项目里，很多这类能力已经被 Next.js 等框架进一步封装。

实践建议

先明确页面是否真的需要 SSR
优先使用成熟框架，不要轻易手写整套 SSR 基建
服务端注水数据必须可序列化
严格处理 hydration mismatch
把渲染策略当作架构决策，而不是框架默认值