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 提前返回,还包括页面头信息可服务端输出:
titlemeta 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
- 把渲染策略当作架构决策,而不是框架默认值
