渲染方式概览

同一套 React 组件，可以在浏览器里画、在服务器上画、或在构建时画成静态文件。先把三条路和水合分清，后面的 RSC、Cache Components 才好谈。

CSR

Client Side Rendering。Vue / 传统 CRA React 都是这条：服务器先丢一个空壳和 JS，浏览器跑脚本、再请求数据、再插入 DOM。

浏览器要页面
  → 服务器给 HTML 骨架 + JS/CSS
  → 浏览器拉 JS
  → JS 再打 API
  → JS 生成 DOM
  → 可以点了
text

优点：交互跟得上，前后端分得干净。
缺点：首屏等 JS；对爬虫不友好（现在多数爬虫会跑 JS，但仍不如直接吐 HTML 稳）。

适合：后台、强交互 SPA、不太在乎 SEO 的工具。

SSR

Server Side Rendering。请求来了，服务器把数据取齐、把组件渲染成完整 HTML 再返回，浏览器先看到内容，再下载 JS，做水合。

浏览器要页面
  → 应用服务器取数
  → 服务器拼出带数据的 HTML
  → 浏览器马上能看
  → 再拉 JS，做 Hydration
  → 可以点了
text

优点：首屏快、SEO 好。
缺点：服务器要干活，流量大时账单和复杂度都上去；开发要同时想两端。

适合：电商、博客、官网首页。Next 的动态页面默认就在这条路上。

SSG

Static Site Generation。next build 时按路由生成 HTML，丢到 CDN / Nginx。用户拿到的是现成文件。

本地 next build
  → 每个路由一份 HTML
  → 部署到 CDN
  → 浏览器要页面，CDN 直接给
  → 再拉 JS，做 Hydration
text

优点：几乎秒开、源站压力小、SEO 最好做。
缺点：数据变了要重新构建（或走 ISR 一类增量）；详情页成千上万时构建会很长。

适合：文档、营销页、不实时变的内容站。本站的笔记页就是按静态思路出的。

Hydration（水合）

服务器（或构建）吐出来的 HTML 是死的：看得到，点了没反应。JS 到了之后，React 拿虚拟树去对真实 DOM，对齐就只绑事件，不对齐就警告并以客户端为准。这个「让静态 HTML 活过来」的过程叫水合。

在 Next 里大致是：

1. 服务器执行组件、取数、序列化成 HTML 给浏览器
2. 用户立刻看见内容
3. 浏览器下载 React 和页面脚本
4. hydrateRoot 对比 DOM，挂上监听
5. 之后的点击、输入走客户端

水合失败最常见的原因：服务器和客户端第一次渲染的结果不一样——Date.now()、window、本地存储、随机数，都会踩坑。能放到 useEffect 里的浏览器 API，就不要在首次 render 里读。

下一篇：RSC 怎么把「服务端一块、客户端一块」拆开，而不是整页一起水合。

参考文档

• Rendering
• Static and Dynamic Rendering
• React hydrateRoot