手帐 Blog

主题

23 · SSR / 同构与水合（决策向） ​

目标：说清何时上 SSR；水合失败常见原因；与 react进阶 互补——这边做决策，那边做 Next 手敲。

1. 背景与目标 ​

SSR / RSC 不是默认正确答案。本篇帮你回答：我的项目要不要服务端出 HTML。

2. 核心概念 ​

名词含义
CSR浏览器拉 JS 再渲染；首屏靠转圈
SSR服务器先吐 HTML，再在浏览器「水合」成可交互应用
同构一套组件两边跑（有约束）
水合 (hydration)把服务端 HTML 与客户端 React/Vue 树接上事件
RSC（Next）服务端组件减少下发 JS；细节见 react 进阶系列
text
要 SEO / 首屏 LCP？ → 倾向 SSR 或静态
强交互后台、已登录 App？ → CSR 往往够
小程序？ → 不是经典浏览器 SSR 模型

3. 决策表（最小实践） ​

问题偏 SSR / 静态偏 CSR
要被搜索引擎收录？是否
首屏关键内容是否纯展示？是大量鉴权后才有数据
能否接受 Node 部署与缓存复杂度？能只想静态托管
团队是否熟水合坑？有人兜底暂无人

水合失败常见因：

  1. 服务端与客户端首次渲染文本不一致（Date.now()、random、window）
  2. 浏览器扩展改 DOM
  3. 非法 HTML 嵌套导致 DOM 纠错

对策：纯展示用服务端时间格式化好再下发；客户端 only 的树挂在 Client 边界；保证合法 DOM。

4. 踩坑与取舍 ​

  1. 为简历强上 SSR：运维与缓存成本被低估。
  2. 处处 useEffect 取数：等于 SSR 了个空壳。
  3. 与微前端叠 SSR：复杂度乘积，慎。
  4. 混用过时 Blog 的 Pages Router 心智：以官方 App Router / 当前栈为准。

5. 验收清单 ​

  • [ ] 用决策表给「当前主项目」写下要 / 不要 SSR 及理由
  • [ ] 能举两例水合 mismatch 原因
  • [ ] 若学 Next：回到 react进阶 README 动手，不在本篇重复脚手架

6. 下一步 ​

→ 24 · 专题复盘合集

参考链接 ​