SSR（Server-Side Rendering，服务器端渲染）是前端页面渲染中常见的一种方案。它的核心思想是：页面 HTML 先在服务端生成，再返回给浏览器展示。相比纯客户端渲染，SSR 通常能带来更快的首屏展示、更好的 SEO 基础和更稳定的内容可见性。
不过，SSR 不是一种固定写法。在实际项目中，SSR 可能采用不同的数据传递方式、渲染模式和缓存策略。不同方式在性能、开发复杂度、SEO、数据安全和交互体验上各有取舍。
一、SSR 渲染方式主要解决什么问题
使用 SSR 通常是为了解决以下问题：
- 首屏加载速度：服务端直接返回完整 HTML，用户更快看到页面主体内容。
- SEO 收录效果：搜索引擎更容易抓取页面中的正文、标题和链接。
- 弱网体验：浏览器不必等待大量 JS 执行后才看到内容。
- 分享预览：社交平台、爬虫和预览工具更容易读取页面 meta 信息。
- 内容稳定性：重要内容在 HTML 中直接存在，减少空白页风险。
但 SSR 也会增加服务端压力、开发复杂度和缓存设计难度。因此，选择哪种 SSR 方式，要结合页面类型和业务目标判断。
二、方式一：HTML 中直接嵌入初始数据
这是最常见的 SSR 方式之一。服务端在生成 HTML 时，把页面需要的初始数据一起写入页面，例如放在 window.__INITIAL_DATA__ 或 JSON script 标签中。浏览器拿到 HTML 后，再用这些数据完成客户端激活。
示例：
<script>
window.__INITIAL_DATA__ = {
title: "文章标题",
content: "文章正文"
}
</script>优点
- 首屏内容完整，SEO 友好。
- 客户端可以直接复用服务端数据，减少二次请求。
- 实现方式成熟，适合 React、Vue、Next.js、Nuxt 等框架。
- 用户看到内容后，页面可以继续变成可交互应用。
缺点
- HTML 体积会变大。
- 数据需要做转义，避免 XSS 风险。
- 如果嵌入数据过多，会拖慢页面下载。
- 服务端和客户端状态需要保持一致，否则可能出现 hydration mismatch。
适用场景
适合文章页、商品详情页、专题页、列表页等需要 SEO 和首屏体验的页面。
三、方式二：服务端只渲染 HTML，客户端再请求数据
这种方式中，服务端返回页面结构和部分基础内容，浏览器加载后再通过接口请求更多数据。
优点
- HTML 更轻，初始响应更小。
- 数据可以按需加载，适合部分动态模块。
- 敏感数据不用直接嵌入 HTML。
- 对缓存更友好，页面结构和动态数据可以分开处理。
缺点
- 首屏内容可能不完整。
- 部分内容需要等待接口返回。
- 如果核心内容依赖客户端请求，SEO 可能受影响。
- 用户可能看到骨架屏或加载状态。
适用场景
适合页面主体可 SSR，但部分评论、推荐、库存、价格、用户状态等模块需要动态加载的页面。
四、方式三：流式 SSR
流式 SSR 是指服务端不必等整页全部渲染完成后再返回，而是边生成边传输 HTML。浏览器可以更早接收到页面片段。
优点
- 首字节和首屏展示可能更快。
- 适合复杂页面和多数据源页面。
- 可以让关键内容优先输出，非关键模块后续补齐。
- 与 React Streaming、Suspense 等能力结合时体验更好。
缺点
- 实现复杂度较高。
- 对框架、服务端运行环境和部署方式有要求。
- 错误处理和缓存策略更难设计。
- 调试成本比普通 SSR 更高。
适用场景
适合内容模块多、接口依赖多、首屏性能要求高的大型页面，例如资讯首页、复杂商品页、聚合页和大型应用入口。
五、方式四：静态生成加增量更新
严格来说，静态生成不是传统意义上的每次请求 SSR，但它常与 SSR 一起比较。它会在构建时或后台预生成 HTML，请求到来时直接返回静态页面；当内容更新后，再增量重新生成。
优点
- 访问速度快，服务器压力低。
- SEO 友好，HTML 内容完整。
- 适合 CDN 缓存。
- 对高并发页面非常友好。
缺点
- 实时性不如请求时 SSR。
- 内容更新后需要触发重新生成。
- 页面数量极多时，构建和缓存管理会变复杂。
- 个性化内容不适合全部静态化。
适用场景
适合文章页、文档页、帮助中心、营销页、商品介绍页等内容相对稳定的页面。
六、方式五：混合渲染
实际项目中，最常见的并不是单一渲染方式，而是混合渲染。比如：
- 文章正文使用 SSR 或静态生成。
- 用户登录状态使用客户端请求。
- 推荐内容使用接口异步加载。
- 价格、库存、权限信息实时请求。
- 热门页面做缓存，低频页面请求时生成。
混合渲染的优势是灵活，可以让 SEO、性能、实时性和开发成本之间取得平衡。
七、几种 SSR 方式的对比
| 渲染方式 | SEO 友好度 | 首屏速度 | 实时性 | 实现复杂度 | 适合页面 |
|---|---|---|---|---|---|
| HTML 嵌入初始数据 | 高 | 较快 | 较好 | 中等 | 文章页、详情页、列表页 |
| SSR + 客户端取数 | 中到高 | 中等 | 高 | 中等 | 动态模块较多的页面 |
| 流式 SSR | 高 | 快 | 较好 | 高 | 大型复杂页面 |
| 静态生成 + 增量更新 | 高 | 很快 | 中等 | 中等 | 内容稳定页面 |
| 混合渲染 | 取决于设计 | 取决于设计 | 灵活 | 中到高 | 大多数复杂业务 |
八、如何选择合适的 SSR 方式
可以按页面类型判断：
- 内容型页面：优先考虑静态生成或 SSR 嵌入初始数据。
- 商品详情页：核心内容 SSR，价格和库存动态请求。
- 资讯首页：可以使用流式 SSR 或缓存 SSR。
- 后台系统：通常不需要 SSR，客户端渲染即可。
- 营销落地页：优先静态化，保证速度和稳定性。
- 搜索结果页：根据实时性和 SEO 需求决定 SSR 或混合渲染。
选择时可以重点看四个问题：
- 页面是否需要搜索引擎收录？
- 首屏速度是否影响转化？
- 数据是否必须实时？
- 页面访问量是否足够高，需要强缓存？
九、SSR 优化时要注意的风险
1. 避免 HTML 中暴露敏感数据
嵌入初始数据时，只放页面渲染必须的数据，不要把用户隐私、权限字段、内部接口信息直接输出到 HTML。
2. 避免 hydration 不一致
服务端渲染结果和客户端渲染结果不一致，会导致页面闪动、报错或交互异常。时间、随机数、浏览器专属 API 都要谨慎处理。
3. 做好缓存策略
SSR 页面如果每次都实时生成，服务器压力会很大。可以结合页面缓存、接口缓存、CDN、增量更新等方式降低成本。
4. 核心内容不要完全依赖客户端渲染
如果页面的标题、正文、重要链接都需要 JS 请求后才出现，SEO 效果可能不稳定。重要内容应尽量在 HTML 中直接可见。
总结
SSR 渲染方式没有绝对最优，只有适不适合当前业务。HTML 嵌入初始数据适合大多数 SEO 页面，SSR + 客户端取数适合动态模块较多的页面，流式 SSR 适合复杂页面性能优化，静态生成适合内容稳定页面，混合渲染则是多数真实项目的常见选择。
在做技术选型时，不要只看框架能力，而要看页面是否需要收录、首屏速度是否重要、数据是否实时、缓存是否可行，以及团队能否承担对应复杂度。只有把 SEO、性能、实时性和维护成本一起考虑，SSR 才能真正发挥价值。
