各种渲染模式
约 785 字大约 3 分钟
2025-10-26
CSR
服务器先返回一个很瘦的 HTML（基本是壳 + JS），浏览器下载 JS 后再请求数据、拼页面。
优点
- 交互体验好：特别适合复杂交互（后台系统、富应用）
- 服务器压力小：主要压力在客户端
- 前后端分离舒服：API + 前端 SPA 很常见
缺点
- 首屏慢：要等 JS 下载/执行完才能看到主要内容
- SEO 相对差：纯 CSR 对搜索引擎不友好（现在也能做，但成本更高）
- 弱网/低端机体验差：JS 重、执行慢就卡
适用场景
后台管理、需要登录后才能看内容的应用、强交互 web app。
SSR
用户请求页面 → 服务器把页面渲染成 HTML（通常也会拉取数据）→ 返回完整 HTML → 浏览器“水合”（hydrate）接管交互。
优点
- 首屏快：第一时间就有 HTML 内容
- SEO 友好：搜索引擎更容易抓取
- 分享预览好：社交平台爬虫能读到内容（标题、摘要、OG 图）
缺点
- 服务器成本更高：每次请求都要渲染
- 复杂度高：同构代码、hydration、缓存、首屏数据、状态一致性
- TTFB 可能变长：服务器渲染花时间（但换来首屏更完整）
适用场景
内容型页面、营销页、电商商品详情、文章页、对 SEO/首屏特别敏感的页面。
SSG
构建时（build）就把每个页面生成静态 HTML 文件，部署到 CDN，用户请求直接拿静态文件。
优点
- 最快（通常）：CDN 直接回静态 HTML
- 最便宜、最稳：几乎不需要服务器渲染
- 安全：攻击面更小（主要是静态资源）
缺点
- 内容更新不实时：更新要重新 build + 发布
- 页面数量多会 build 很慢：比如几万篇文章、很多商品页
- 个性化难：基于用户实时数据要靠客户端再请求
适用场景
文档站、博客、活动页、公司官网、内容更新不频繁的站点。
ISR
常见于 Next.js 概念，Nuxt 生态里也有类似的“按需重新生成/缓存失效再生成”的思路（不同平台实现细节会不一样）。
页面先按 SSG 方式生成并走 CDN。之后：
- 可以设置 定时重新生成（比如每 60 秒允许更新一次）
- 或者 某个页面被访问时发现过期，后台再生成新版本并替换缓存 （用户可能拿到旧的，但很快会变新）
优点
- 兼顾 SSG 性能 + SSR 更新能力
- 大站友好：不用每次全量 build，内容更新更灵活
- 成本更可控：绝大多数流量仍是静态
缺点
- 一致性是“最终一致”：短时间内可能有人看到旧内容
- 缓存策略复杂：什么时候过期、怎么触发更新、怎么回源
- 依赖平台能力：部署环境要支持这种缓存/重建模型
适用场景
电商商品、新闻、内容量大且经常更新但又想保持静态性能的站。