Next.js 渲染策略全解:SSR、SSG、ISR 的原理、取舍与生产级实践
Next.js 的核心价值在于它把 React 从纯客户端渲染扩展到了服务端。但很多新手踩的坑是——分不清什么时候用 SSR、什么时候用 SSG、什么时候该上 ISR。
三种渲染模式对比
| 策略 | 渲染时机 | 适用场景 | SEO | 性能 |
|---|---|---|---|---|
| SSR | 每次请求时 | 个性化内容、实时数据 | 好 | 中 |
| SSG | 构建时 | 博客、文档、营销页 | 好 | 优 |
| ISR | 构建时 + 按需更新 | 内容不频繁变化的页面 | 好 | 优 |
| CSR | 浏览器端 | 后台管理、仪表盘 | 差 | 差 |
SSR:每次请求动态渲染
SSR 在请求到达时在服务端执行 React 组件,生成完整 HTML 返回。适合用户千人千面的场景——比如用户个人主页、购物车、实时仪表盘。代价是每个请求都需要服务端计算,TTFB 比静态文件高。
SSG:构建时一张到底
SSG 在构建时预渲染所有页面为静态 HTML,部署后直接返回静态文件。这是性能最优的方案——零服务端计算、CDN 友好、SEO 满分。适合博客文章、文档、营销落地页。
ISR:静态页面的按需更新
ISR 是 Next.js 的杀手级特性——它允许 SSG 页面定期后台重新生成,不需要重新构建整个站点。内容发布后,首次请求返回旧版本,后台触发重新生成,后续请求获得最新内容。
App Router vs Pages Router
Next.js 13+ 引入了 App Router,核心变化:React Server Components(默认服务端组件)、基于文件系统的 layouts/loading/error 约定、流式渲染。新项目优先选择 App Router。
选型决策树
- 内容频繁变化 + 每次都要最新数据 → SSR
- 内容在构建时可确定 → SSG
- 内容偶尔更新但不想重新构建 → ISR
- 不需要 SEO 的纯交互应用 → CSR
总结
Next.js 的三种渲染策略覆盖了从完全静态到完全动态的全光谱。SSG 是默认最优解,ISR 是静态站点的动态化升级,SSR 是动态场景的最后选择。理解了它们的差异,你就掌握了现代 React 应用架构的核心。
本文是原创文章,采用CC BY-NC-SA 4.0协议,完整转载请注明来自CC 的技术工坊
