28 对Vue SSR的理解

Vue.js 是构建客户端应用程序的框架。默认情况下，可以在浏览器中输出 Vue 组件，进行生成 DOM 和操作 DOM。然而，也可以将同一个组件渲染为服务端的 HTML 字符串，将它们直接发送到浏览器，最后将这些静态标记"激活"为客户端上完全可交互的应用程序。

SSR也就是服务端渲染，也就是将 Vue 在客户端把标签渲染成 HTML 的工作放在服务端完成，然后再把 html 直接返回给客户端

• 优点 ：SSR 有着更好的 SEO、并且首屏加载速度更快
  • 因为 SPA 页面的内容是通过 Ajax 获取，而搜索引擎爬取工具并不会等待 Ajax 异步完成后再抓取页面内容，所以在 SPA 中是抓取不到页面通过 Ajax获取到的内容；而 SSR 是直接由服务端返回已经渲染好的页面（数据已经包含在页面中），所以搜索引擎爬取工具可以抓取渲染好的页面
  • 更快的内容到达时间（首屏加载更快）： SPA 会等待所有 Vue 编译后的 js 文件都下载完成后，才开始进行页面的渲染，文件下载等需要一定的时间等，所以首屏渲染需要一定的时间；SSR 直接由服务端渲染好页面直接返回显示，无需等待下载 js 文件及再去渲染等，所以 SSR 有更快的内容到达时间
• 缺点 ： 开发条件会受到限制，服务器端渲染只支持 beforeCreate 和 created 两个钩子，当我们需要一些外部扩展库时需要特殊处理，服务端渲染应用程序也需要处于 Node.js 的运行环境。服务器会有更大的负载需求
  • 在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用CPU资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 ( high traffic ) 下使用，请准备相应的服务器负载，并明智地采用缓存策略

其基本实现原理

• app.js 作为客户端与服务端的公用入口，导出 Vue 根实例，供客户端 entry 与服务端 entry 使用。客户端 entry 主要作用挂载到 DOM 上，服务端 entry 除了创建和返回实例，还进行路由匹配与数据预获取。
• webpack 为客服端打包一个 Client Bundle ，为服务端打包一个 Server Bundle 。
• 服务器接收请求时，会根据 url，加载相应组件，获取和解析异步数据，创建一个读取 Server Bundle 的 BundleRenderer，然后生成 html 发送给客户端。
• 客户端混合，客户端收到从服务端传来的 DOM 与自己的生成的 DOM 进行对比，把不相同的 DOM 激活，使其可以能够响应后续变化，这个过程称为客户端激活 。为确保混合成功，客户端与服务器端需要共享同一套数据。在服务端，可以在渲染之前获取数据，填充到 stroe 里，这样，在客户端挂载到 DOM 之前，可以直接从 store里取数据。首屏的动态数据通过 window.__INITIAL_STATE__发送到客户端

Vue SSR 的实现，主要就是把 Vue 的组件输出成一个完整 HTML, vue-server-renderer 就是干这事的

Vue SSR需要做的事多点（输出完整 HTML），除了complier -> vnode，还需如数据获取填充至 HTML、客户端混合（hydration）、缓存等等。相比于其他模板引擎（ejs, jade 等），最终要实现的目的是一样的，性能上可能要差点

补充(现代做法)：上文基于 Vue2 的 vue-server-renderer + 双 webpack bundle 是较早的手工方案，实际项目几乎不再裸写。现在优先用 Nuxt 3（Vue3 + Vite + Nitro 引擎）开箱即用地拿到 SSR/SSG/ISR、自动路由与数据预取。Vue3 自身用 @vue/server-renderer 的 renderToString，并配合 createSSRApp（而非 createApp）来生成可水合的应用。除了全量 SSR，还可考虑 SSG（静态站点生成） 与「岛屿架构 / 部分水合」来进一步降低首屏 JS 与 TTI；window.__INITIAL_STATE__ 的状态注入思路在 Pinia 中改用 pinia.state.value 序列化/反序列化。