弟弟森的编程小笔记

外观

现代前端渲染模式

约 1365 字大约 5 分钟

2026-01-21

1.SPA

SPA（Single Page Application）单页应用，通常指代 "客户端渲染" 的 Vue/React 应用。它的特点是：只有一个 HTML 页面入口，页面切换通过前端路由实现，内容由 JS 渲染生成

SPA 应用的具体流程
  1. 浏览器请求 SPA 应用
  2. 服务器返回空壳 HTML 与 JS/CSS 资源
  3. 浏览器开始下载资源并执行脚本，脚本发起数据请求并生成 DOM

由于需要等待脚本与数据到位，因此首屏常见的现象是白屏或 Loading，而当脚本加载完成后，页面进入高交互、低刷新成本的状态，路由切换只是局部 DOM 更新，不再需要重新加载完整页面

相关信息

首屏内容必须等待脚本下载与执行，任何网络波动、包体积膨胀或数据接口延迟都会直接拉长首屏时间。也就是说客户端渲染把 "是否可见" 的决定权交给了 JS

从体验角度看，SPA 能提供接近原生应用的切换流畅度与交互一致性；从工程角度看，组件化、前端路由与统一状态管理会显著提升复杂交互的可维护性。与此同时，SPA 也会把大量逻辑推到客户端，使首屏依赖的 JS 体积变大，SEO 也会因为 "空壳 HTML" 而变得困难，这些代价在大型项目中尤其明显

2.SSG

SSG（Static Site Generation）静态站点生成，SSG 的逻辑是把渲染前移到构建阶段，构建时会为每个路由生成完整 HTML 文件，部署后用户请求直接命中静态文件，速度接近纯静态站点。由于首屏 HTML 已经完整生成，SEO 通常非常友好，且服务器开销较小。

相关信息

SSG 的限制在于 "内容变更成本" 一旦页面数据发生变化，就需要重新构建并部署才能生效，因此它更适合内容更新频率较低的站点，例如文档、博客或营销页

3. SSR

SSR（Server Side Rendering）服务端渲染，其核心在于由服务端先生成完整的 HTML，再将结果返回给浏览器进行展示，无需等待 JS 执行

这种方式兼顾了 SEO 与首屏性能，是 SPA 在这两个维度上的重要优化手段，但每次请求都要在服务器端渲染，因此对服务器资源与工程复杂度提出更高要求

注

SSR 用更高的服务器成本换取更快的首屏与更好的 SEO 并通过 Hydration 保留 SPA 的交互体验。代价是必须同时兼顾服务端与客户端环境，处理数据预取、状态注水与渲染一致性等问题

这里以 Vue + Node 中间层的实现为例，说明 SSR 的核心流程与关键节点

  1. 双入口与双产物

    SSR 会在构件时产生两份产物，分别为运行在 Node 环境中的 server bundle 与运行在浏览器环境中的 client bundle。两份 bundle 共享同一套组件与路由

  2. 简要的请求过程

    请求链路, 以请求 /home 为例
    1. Node 接收请求后，为该请求创建一个全新的 SSR 应用实例
    2. 服务端创建路由并将其推进到当前 URL，然后等待 router.isReady()，以保证路由解析完成并与目标页面匹配
    3. 服务端执行数据预取逻辑，确保渲染前数据齐全
    4. 服务端调用 renderToString() 将应用渲染为 HTML 字符串，得到 appHtml
    5. 服务端将 appHtml 注入到 HTML 模板的占位符中
    6. 浏览器收到 HTML 后立即渲染页面内容，此时页面可见但还不可交互
    7. 浏览器下载 client_bundle.js 并执行客户端入口脚本，创建客户端应用实例并恢复初始状态
    8. 客户端执行 Hydration，将已有 DOM 与虚拟 DOM 对齐并绑定事件，页面转为可交互的 SPA
    9. 后续的路由切换与状态更新都发生在客户端，表现为常规 SPA 的体验

  3. 模板注入

    服务端渲染的核心产物是 HTML 字符串，它通常会被注入到模板中，形成最终响应

    模板.html
    <body>
  <div id="app"><!--app--></div>
  <script src="/client_bundle.js"></script>
</body>

    当 <!--app--> 被 appHtml 替换后，浏览器得到的是可直接渲染的完整内容，这就是 SSR 首屏快的根本原因

  4. 数据预取与状态注水

    为避免 "服务端已渲染、客户端还要再请求一遍" 的重复开销，SSR 会在服务端中先完成数据预先获取，再把数据写入本次请求的 store 实例，然后在将状态序列化为 window.__INITIAL_STATE__ 注入页面，该过程被称为 脱水 dehydrate

    后续客户端启动时将会读取这份初始状态并将其恢复到客户端 store，以保证两端首屏内容一致并减少额外请求，该过程被称为 注水 rehydrate