SSR、CSR 和 SSG 有什么区别？

简化版

CSR 是浏览器下载 JS 后在客户端渲染页面；SSR 是服务器运行前端代码生成 HTML，再发送给浏览器；SSG 是构建时预生成 HTML。CSR 交互灵活，SSR 首屏和 SEO 更好，SSG 性能和稳定性好但适合内容较静态的页面。

三者对比：

选择依据：

SSR 和 SSG 都能改善首屏内容可见性，但 SSR 有服务端运行成本，SSG 有构建和内容更新限制。

CSR 是现代 SPA 常见模式。服务器返回基础 HTML，主要内容由浏览器执行 JS 后生成。

它的优势是交互体验好、前后端分离清晰、部署简单。缺点是首屏依赖 JS 下载和执行，SEO 也可能受影响。

后台管理系统、强交互工具类产品通常适合 CSR。

SSR 在请求到来时，由服务端渲染出 HTML。用户可以更快看到内容，搜索引擎也更容易抓取。

但 SSR 需要 Node 服务或相应运行时，涉及缓存、并发、数据获取、错误处理和部署复杂度。

SSR 适合内容动态且需要 SEO 的页面，比如电商详情、资讯详情。

SSG 在构建时把页面生成静态 HTML。请求时直接走 CDN 或静态服务器，速度快、成本低、稳定性好。

缺点是内容变化后需要重新构建或增量更新。对于文档、博客、题库、营销页，SSG 非常适合。

面试官可能问：“SSR 一定比 CSR 快吗？”

不一定。SSR 能更快返回可见 HTML，但如果服务器慢、水合 JS 大、接口阻塞严重，整体体验仍可能差。最终要看 TTFB、LCP、Hydration 时间和交互可用时间。

工程选型不是追概念，而是看 SEO、首屏、交互复杂度、内容更新频率和部署成本。

假设 API 取数 200ms、服务端渲染 50ms、浏览器 JS 下载执行 400ms：SSR 可能约 250ms 后收到有内容 HTML，但交互仍要等 JS；CSR 可能较早收到空壳，却约 600ms 后才出现主体；SSG 命中 CDN 可能几十毫秒返回内容。实际还受并行、缓存和网络影响。

不要只比较 TTFB：还要看 LCP、客户端 JS、水合结束、INP、服务器成本和内容陈旧度。

逐页问四个问题：是否公开需要 SEO？内容多久变化？是否按用户个性化？首屏交互是否强于内容？公开稳定内容优先 SSG；公开且高频变化可 SSR/ISR；登录后强交互工具通常 CSR。

需要公开抓取？
├─ 否 → 强交互/个性化：CSR 为主
└─ 是 → 内容能构建时确定？
        ├─ 是 → SSG/ISR
        └─ 否 → SSR，配缓存与客户端水合

一个电商站可以让营销页 SSG、商品公共信息 ISR、库存客户端实时刷新、购物车 CSR、首个商品请求 SSR。混合不是妥协，而是把计算放在最合适的时间和位置。

选型还要算峰值。若 SSR 每次占 50ms CPU、峰值 2000 QPS，理论需要约 100 CPU 核心的纯渲染时间；缓存命中 90% 可显著降低成本。没有容量模型就说“SSR 更快”是不完整的。