Next.js 的核心价值在于它把 React 从纯客户端渲染扩展到了服务端。但很多新手踩的坑是——分不清什么时候用 SSR、什么时候用 SSG、什么时候该上 ISR。

三种渲染模式对比

策略 渲染时机 适用场景 SEO 性能
SSR 每次请求时 个性化内容、实时数据 好 中
SSG 构建时 博客、文档、营销页 好 优
ISR 构建时 + 按需更新 内容不频繁变化的页面 好 优
CSR 浏览器端 后台管理、仪表盘 差 差

我的踩坑记：ISR 没更新的 3 天

做个内容站时我选了 ISR，revalidate 设成 60 秒。结果主编发了新文章，三天了首页还是旧的。排查发现：我把 revalidate 写在了客户端组件里（开头加了 “use client”），而 ISR 的 revalidate 只对服务端组件生效。

更隐蔽的坑是：ISR 的后台重新生成依赖”有请求触发”——如果那个页面三天空无一人访问，它永远不会更新。最终方案是改用 on-demand revalidation，通过 webhook 在发布文章时主动调用 revalidatePath。ISR 不是”自动更新”，而是”下次请求时更新”——这个认知差异坑了我三天。

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 应用架构的核心。