服务端渲染的发展历史
传统的服务端渲染
传统的服务端渲染有 asp, jsp(java), ejs(nodejs)等，服务端语言往往通过这些模板引擎将数据 data 和 html 结构在服务端组装，返回一个完整的静态的 html 字符串给客户端，由客户端直接显示。
缺点
- 前后端不分离，前后端代码混在一个工程目录中，维护不方便，。
- 用户体验不佳，每次页面有改动都需要重新加载整个页面。比如，一个列表页面，当用户增加一项时，后台需要重新组装数据
data 和 html 结构，返回一个新的页面给前端，这样用户才能看到页面的变化。
- 服务端压力大，不仅要响应静态
html 文件，还要响应数据api接口。
客户端渲染(CSR)
在现代化的前端项目中，客户端渲染的代表性技术栈是 vue/react/angular，我们常常使用它们来构建客户端单页或者多页应用程序。
以 SPA 构建程序为例，在浏览器端首先渲染的是一套空的 html，然后下载bundle.js并执行，通过 JavaScript 直接进行页面的渲染和路由跳转等操作，所有的数据通过 ajax 请求从服务端获取。
路由的跳转是通过history api 实现的，它最大的作用是能改变url地址，但是不会刷新页面，也就是不会发送请求。这样对用户操作来说就非常的无感，克服了传统服务端渲染每次都要请求服务器的困扰。
缺点
- 首屏加载慢，因为第一次会请求一个空的
html文件，再去加载 bundle.js等打包后的文件。
- 不利于网站
SEO，因为首次请求回来的是空的 html 文件，爬虫无法获取有效内容信息，其实现在的爬虫也能爬取spa网站了。
现代服务端渲染(同构)
我们现在讲的服务端渲染概念，是指在前端范畴或者说在 Vue/React 等单页面技术范畴内的，基于 Nodejs server 运行环境的服务端渲染方案，这种方案的本质是同构渲染。它的步骤如下：
- 在
Nodejs 中运行相同的前端代码，将用Vue/React框架写的代码转化为html 结构，然后返回给浏览器渲染，这样爬虫就能爬取到完整的页面信息。
- 客户端获取到服务端返回的页面后，再进行注水(hydrate)化处理，由客户端代码(SPA代码)来接管页面。
为什么要进行注水处理呢？
因为服务端环境毕竟不同于浏览器环境，缺少浏览器环境必要的变量和API。比如，页面中的点击事件就无法在服务端进行注册，因为在服务端环境中是没有DOM节点的概念的，它只是一堆字符串而已，自然无法使用 document.addEventListener 这样的API。也就是如果客户端代码不接管页面，那么页面里面所有的点击事件将不可用。
什么是同构？
同构简单来讲就是服务端和客户端复用同一套代码。比如，页面html结构、store数据存储、router路由都能共享一套代码。这就是所谓的现代服务端渲染：同构。
缺点
- SSR 的数据获取必须在组件渲染之前；
- 组件的 JavaScript 必须先加载到客户端，才能开始水合；
- 所有组件必须先水合，然后才能跟其中任意一个组件交互；
可以看出 SSR 这种技术大开大合，加载整个页面的数据，加载整个页面的 JavaScript，水合整个页面，还必须按此顺序串行执行。如果有某些部分慢了，都会导致整体效率降低。
此外，SSR 只用于页面的初始化加载，对于后续的交互、页面更新、数据更改，SSR 并无作用。
为什么选择 SSR？
相比于客户端渲染 CRS (单页面应用)，SSR 主要的好处是：
更快的内容呈现
尤其是网络连接缓慢或设备运行速度缓慢的时候，服务端标记不需要等待所有的 JavaScript 脚本都被下载并执行之后才显示，所以用户可以更快看到完整的渲染好的内容。这带来了更好的用户体验，同时对于内容呈现时间和转化率呈正相关的应用来说尤为关键。
更好的搜索引擎优化 (SEO)
因为后端会一次性的把网站内容返回给前端，所以搜索引擎爬虫会直接读取完整的渲染出来的页面。但如果你的JavaScript 脚本是通过 API 调用获取内容，则爬虫不会等待页面加载完成。这意味着如果你的页面有异步加载的内容且 SEO 很重要，那么你可能需要 SSR。
除了上面两个优点外，这里还有一些点来决定是是否选用SSR：
-
开发一致性。浏览器特有的 API 只能在特定的生命周期钩子中使用；一些外部的库在服务端渲染应用中可能需要经过特殊处理。
-
需要更多的构建设定和部署要求。不同于一个完全静态的 SPA 可以部署在任意的静态文件服务器，服务端渲染应用需要一个能够运行
Nodejs 服务器的环境。
-
更多的服务端负载。在
Nodejs 中渲染一个完整的应用会比仅供应静态文件产生更密集的 CPU 运算。所以如果流量很高，请务必准备好与其负载相对应的服务器，并采取明智的缓存策略。
在应用中使用 SSR 之前，你需要问自己的第一个问题是：你是否真的需要它？
它通常是由内容呈现时间对应用的重要程度决定的。
例如，如果你正在搭建一个内部管理系统，几百毫秒的初始化加载时间对它来说无关紧要，这种情况下就没有必要使用 SSR。然而，如果内容呈现时间非常关键，SSR 可以助你实现最佳的初始加载性能。
SSR vs 预渲染
如果你仅希望通过 SSR 来改善一些推广页面 (例如 /、/about、/contact 等) 的 SEO，那么预渲染也许会更合适。和使用动态编译 HTML 的 web 服务器相比，预渲染可以在构建时为指定的路由生成静态 HTML 文件。
如果你正在使用 webpack，你可以通过 prerender-spa-plugin 来支持预渲染。
现代服务端渲染(同构)大致实现原理
通过前面的介绍，服务端渲染就是返回一个带有具体内容的 html 字符串给浏览器，那么这个具体的内容是什么呢？
这个具体的内容就是用 Vue 开发的页面内容，但是如果直接把带有 Vue 语法塞进 html 模板浏览器根本无法识别，因此，服务端渲染也需要使用 Vite 进行编译打包转化为浏览器能识别的javascript语法。
根据同构概念理解，客户端和服务端是共用同一套的页面内容代码的，所以客户端和服务端需要分别打包编译。
首先就是编写通用代码，适用于客户端和服务端。
一. 编写通用代码
由于平台 API 的差异，当运行在不同环境中时，我们写的通用代码将与纯客户端代码不会完全相同。需要注意一下几点：
1. 避免状态单例
在纯客户端应用程序中，每个用户会在他们各自的浏览器中使用新的应用程序实例。对于服务器端渲染，我们也希望如此。
但是，Node.js 服务器是一个长期运行的进程。当我们的代码进入该进程时，它将进行一次取值并留存在内存中。这意味着如果创建一个单例对象，它将在每个传入的请求之间共享。
所以，必须要求每个请求都应该都是全新的、独立的应用程序实例，以便不会有交叉请求造成的状态污染。
因此，我们不应该直接创建一个应用程序实例，而是应该暴露一个可以重复执行的工厂函数，为每个请求创建新的应用程序实例：
对原有客户端代码代码进行改造：
main.js：
# 原有代码
const app = createApp(App)
app.config.globalProperties.$message = ElMessage
app.use(router)
app.use(store, key)
app.use(ElementPlus)
app.use(i18n)
app.mount('#app')
# 改造后代码：变为工厂函数
import { createSSRApp } from 'vue'
export function createApp() {
const app = createSSRApp(App)
const store = createSSRStore()
const router = createSSRRouter()
const i18n = createSSRI18n()
sync(store, router)
app.config.globalProperties.$message = ElMessage
app.use(store, key)
app.use(router)
app.use(ElementPlus)
app.use(i18n)
return { app, router, store }
}
同理，项目中的数据存储store，路由router等都需要改造成工厂函数的形式，比如路由：
export function createSSRRouter() {
return createRouter({
# import.meta.env.SSR是vite提供环境变量
# 服务端渲染只能用createMemoryHistory
history: import.meta.env.SSR ? createMemoryHistory() : createWebHistory(),
routes
})
}
2. 组件生命周期钩子函数
由于服务端没有动态更新，所有的生命周期钩子函数中，只有 beforeCreate 和 created 会在服务器端渲染 (SSR) 过程中被调用。这就是说任何其他生命周期钩子函数中的代码（例如 beforeMount 或 mounted），只会在客户端执行。
此外还需要注意的是，你应该避免在 beforeCreate 和 created 生命周期时产生全局副作用的代码，例如在其中使用 setInterval 设置 timer。在纯客户端的代码中，我们可以设置一个 timer，然后在 beforeDestroy 或 destroyed 生命周期时将其销毁。但是，由于在 SSR 期间并不会调用销毁钩子函数，所以 timer 将永远保留下来。
3. 访问特定平台API
通用代码不可接受特定平台的 API，因此如果你的代码中，直接使用了像 window 或 document，这种仅浏览器可用的全局变量，则会在 Node.js 中执行时抛出错误，反之也是如此。
对于共享于服务器和客户端，但用于不同平台 API 的任务，建议将平台特定实现包含在通用 API 中，例如，axios是一个 HTTP 客户端，可以向服务器和客户端都暴露相同的 API。
请注意，考虑到如果第三方 library 不是以上面的通用用法编写，则将其集成到服务器渲染的应用程序中，可能会很棘手。
二、 构建步骤
编写好通用代码之后，就需要使用构建工具webpack, Vite进行打包构建，我们将会采用Vite进行构建，构建过程如下:
1. 创建客户端入口和服务端入口文件
一个典型的 SSR 应用应该有如下的源文件结构：
- index.html # 模版html文件
- server.ts # main application server
- src/
- main.js # 公共通用代码，不是入口文件
- entry-client.ts # 客户端入口： 将应用挂载到一个 DOM 元素上
- entry-server.ts # 服务端入口：使用某框架的 SSR API 渲染该应用
index.html
首先看下index.html文件，它原来长这个样子：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<link rel="icon" type="image/svg+xml" href="/vite.svg" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>一个经典的前台项目</title>
</head>
<body>
<div id="app"></div>
<script type="module" src="/src/main.js"></script>
</body>
</html>
<script type="module" src="/src/main.js"></script>中的type="module"的含义与带 defer 的普通脚本一致：
- 不会阻塞 HTML 解析；
- 会等待 HTML 解析完成后，按脚本在页面中的顺序执行；
- 普通脚本（无
defer/async）会阻塞解析，执行完才继续解析 HTML。
开发完代码后，执行npm run build进行打包后长这个样子：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<link rel="icon" type="image/svg+xml" href="/vite.svg" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>一个经典的前台项目</title>
<script type="module" crossorigin src="/assets/index-IiCrRs2g.js"></script>
<link rel="stylesheet" crossorigin href="/assets/index-NLCfHQLN.css">
</head>
<body>
<div id="app"></div>
</body>
</html>
其中的index-IiCrRs2g.js是整个前端应用的核心入口文件，其核心作用是启动 Vue 应用、挂载根组件，并加载应用运行所需的核心依赖 / 资源。
现在需要改造如下：
index.html 将需要引用 entry-client.ts，而不是原来的main.ts，并包含一个占位标记供给服务端渲染时注入：
<div id="app"><!--ssr-outlet--></div>
<script type="module" src="/src/entry-client.ts"></script>
服务端渲染后的html字符串会替换<!--ssr-outlet-->，/src/entry-client.ts代码主要是用于接管页面，使其具备交互能力。
entry-client.ts
import { createApp } from './main'
const { app, router, store } = createApp()
router.isReady().then(() => {
app.mount('#app')
})
entry-server.ts
import { createApp } from './main'
import { renderToString } from '@vue/server-renderer'
// 服务端渲染核心函数
export async function render(url) {
const { app, router, store } = createApp()
# 根据url来渲染对应的页面
await router.push(url)
await router.isReady()
const appHtml = await renderToString(app)
return appHtml
}
server.ts
const fs = require('fs')
const path = require('path')
const express = require('express')
const serveStatic = require('serve-static')
const { createServer: createViteServer } = require('vite')
async function createServer() {
const app = express()
const vite = await createViteServer({
server: { middlewareMode: 'ssr' }
})
app.use(vite.middlewares)
app.use('*', async (req, res) => {
const url = req.originalUrl
# 1. 读取 index.html
let template = fs.readFileSync(path.resolve(__dirname, 'index.html'),
'utf-8')
template = await vite.transformIndexHtml(url, template)
# 2. entry-server.ts 暴露了render方法
let render = (await vite.ssrLoadModule('/src/entry-server.ts')).render
# 3. 根据url渲染对应的
const appHtml = await render(url)
# 4. 插入到div中
const html = template.replace('<!--ssr-outlet-->', appHtml)
res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
})
app.listen(3000, () => {
console.log('node server run at:', isProd ? '生产环境' : '开发环境')
})
}
createServer()
package.json
package.json 中的 dev 脚本也应该相应地改变，使用服务器脚本：
"scripts": {
// "dev": "vite"
"dev": "cross-env NODE_ENV=development node server.js",
}
2. 打包客户端和服务端代码
package.json 中的脚本应该看起来像这样：
{
"scripts": {
"dev": "node server",
"build:client": "vite build --outDir dist/client",
"build:server": "vite build --outDir dist/server --ssr src/entry-server.js "
}
}
使用 --ssr 标志表明这将会是一个 SSR 构建，同时需要指定 SSR 的入口。
接着，在 server.js 中，通过 process.env.NODE_ENV 条件，需要添加一些用于生产环境的特定逻辑：
-
index.html模版变更：使用 dist/client/index.html 作为模板，而不是根目录的 index.html，因为前者包含了到客户端构建的正确资源链接。
- 服务端入口文件变更：原来是
/src/entry-server.js， 现在要使用 import('./dist/server/entry-server.js')。
修改后代码如下:
const fs = require('fs')
const path = require('path')
const express = require('express')
const serveStatic = require('serve-static')
const { createServer: createViteServer } = require('vite')
const isProd = process.env.NODE_ENV === 'production'
async function createServer() {
const app = express()
const vite = await createViteServer({
server: { middlewareMode: 'ssr' }
})
# 在生产环境需要vite与express进行脱钩
if (!isProd) {
# 使用 vite 的 Connect 实例作为中间件，利用这个中间件来起一个静态资源服务器
app.use(vite.middlewares)
} else {
# 在生产环境，利用express框架自带的中间件serve-static，利用这个中间件来起一个静态资源服务器
# 把dist/client文件夹下的资源都可以访问
app.use(
serveStatic(path.resolve(__dirname, 'dist/client'), { index: false })
)
}
app.use('*', async (req, res) => {
const url = req.originalUrl
let template
let render
try {
# 在生产环境需要vite与express进行脱钩
if (!isProd) {
// 1. 读取 index.html
template = fs.readFileSync(
path.resolve(__dirname, 'index.html'),
'utf-8'
)
# 2. 应用 Vite 进行 HTML 转换，这将会注入 Vite HMR 客户端，
template = await vite.transformIndexHtml(url, template)
# 3. 加载服务器入口文件，vite.ssrLoadModule 将自动转换你的 ESM 源码使之可以在 Node.js 中运行。既然是加载文件，肯定是异步的，所以使用await
render = (await vite.ssrLoadModule('/src/entry-server.ts')).render
} else {
# 1. 生产环境需要加载编译后的模版文件index.html
template = fs.readFileSync(
path.resolve(__dirname, 'dist/client/index.html'),
'utf-8'
)
# 2. 使用SSR构建后的最终render函数
render = require('./dist/server/entry-server.js').render
}
# 4. 渲染应用的 HTML
const appHtml = await render(url, manifest)
# 5. 注入渲染后的应用程序 HTML 到模板中。
const html = template
.replace('<!--ssr-outlet-->', appHtml)
// 6. 返回渲染后的 HTML。
res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
} catch (e) {
...
}
})
app.listen(3000, () => {
console.log('node server run at:', isProd ? '生产环境' : '开发环境')
})
}
createServer()
三、数据获取
在服务器端渲染(SSR)期间，我们本质上是在渲染我们应用程序的"快照"，所以如果应用程序依赖于一些异步数据，那么在开始渲染过程之前，需要先预取和解析好这些数据。
另一个需要关注的问题是在客户端代码接管时，需要获取到与服务器端应用程序完全相同的数据，否则客户端应用程序会因为使用与服务器端应用程序不同的状态，然后导致水合失败。
为了解决这个问题，获取的数据需要位于视图组件之外，即放置在专门的数据预取存储容器(data store)或"状态容器(state container)"中。
为此，我们将使用官方状态管理库 Vuex。
那么，我们在哪里放置dispatch 数据预取 action的代码？
事实上，给定路由所需的数据，也是在该路由上渲染组件时所需的数据。所以在路由组件中放置数据预取逻辑，是很自然的事情。
我们将在路由组件上暴露出一个自定义静态函数 asyncData。注意，由于此函数会在组件实例化之前调用，所以它无法访问 this。需要将 store 和路由信息作为参数传递进去：
<script setup>
import { ref } from 'vue'
async function asyncData({ store, route }: any) {
return store.dispatch('getRoomList')
}
defineExpose({ asyncData })
</script>
1. 服务器端数据预取
在 entry-server.js 中，我们可以通过路由获得相匹配的组件，如果组件暴露出 asyncData，我们就调用这个方法。然后我们需要将解析完成的数据，绑定到到window上。
修改entry-server.ts:
export async function render(url: string, manifest: any) {
const { app, router, store } = createApp()
await router.push(url)
await router.isReady()
const matchedComponents = router.currentRoute.value.matched.flatMap(record =>
Object.values(record.components)
)
await Promise.all(
matchedComponents.map((Component: any) => {
# 如果组件中定义了asyncData函数，说明这个组件需要去后台获取接口数据
if (Component.asyncData) {
return Component.asyncData({
// 传入store和当前route，store参数用来执行store.dispatch，发起请求
store,
route: router.currentRoute
})
}
return []
})
)
const appHtml = await renderToString(app)
# 此时state里面包含了请求接口获取的数据，然后就把这个数据绑定到window某个属性上
# 这样当同构的时候，客户端的store.state就能用这个值作为初始化化数据，就不用再去调一次接口了
const state = store.state
return { appHtml, state }
}
修改模板文件index.html:
<div id="app"><!--ssr-outlet--></div>
<script type="module" src="/src/entry-client.ts"></script>
<script>
window.__INITIAL_STATE__ = '<!--vuex-state-->'
</script>
修改server.ts
const { appHtml, state } = await render(url)
const html = template
.replace('<!--ssr-outlet-->', appHtml)
.replace("'<!--vuex-state-->'", JSON.stringify(state))
修改entry-client.js: 使用__INITIAL_STATE__来初始化store，这样客户端接管时也是带有数据的。
const { app, router, store } = createApp()
if ((window as any).__INITIAL_STATE__) {
store.replaceState((window as any).__INITIAL_STATE__)
}
2. 客户端数据预取
首先思考下为什么会有客户端数据预取？
当我从服务端请求页面内容(/login)后，客户端代码立即接管页面，此时页面跳转时不会再向服务端发送请求了。
当从/login页面跳转到/home页面，由于组件的部分生命周期在服务端不能使用，我们没有在代码中写onMounted钩子函数，也就无法执行获取接口的函数，那么此时/home页面是没有数据的。所以就需要在客户端进行数据预取，既然组件生命周期钩子不能用，还有什么钩子可以用呢？
答案是路由钩子。
修改entry-client.ts:
router.isReady().then(() => {
# beforeResolve表示所有的异步组件全部resolve了
router.beforeResolve((to, from, next) => {
# 找出两个匹配列表的差异组件。
# 如果你刷新当前页面，会发送请求到服务器，服务前拼接好数据和html返回前端，但是有了这个路由钩子，它还会再去请求一遍数据，这就相当于前后台都去请求了一次回去，这没有必要。
# 所以需要做一个判断是否是在刷新页面，也就是to和from是不是一样的，如果一样的，就是刷新操作，那么actived为空，不会执行后面的逻辑，也就是客户端不会再次请求数据接口，用服务端带过来的数据就可以了，这就是防止客户端数据二次预取。
const toComponents = router
.resolve(to)
.matched.flatMap(record => Object.values(record.components))
const fromComponents = router
.resolve(from)
.matched.flatMap(record => Object.values(record.components))
const actived = toComponents.filter((c, i) => {
return fromComponents[i] !== c
})
# 客户端预取数据有两种方式：
# 一种是在匹配到路由视图之后就跳转，然后去请求接口，
# 另一种是在请求接口数据返回后再进行跳转，此时页面是包含数据的
if (!actived.length) {
return next()
} else {
# 第一种： 匹配路由之后直接跳转，然后去请求接口
// next()
}
// 显示loading
const loadingInstance = ElLoading.service({
lock: true,
text: 'Loading',
background: 'rgba(0, 0, 0, 0.7)'
})
Promise.all(
actived.map((Component: any) => {
if (Component.asyncData) {
return Component.asyncData({
store,
route: router.currentRoute
})
}
return []
})
).then(() => {
// 关闭loading
loadingInstance.close()
# 第二种： 等数据请求之后再跳转
next()
})
})
app.mount('#app')
})
至此，整个服务端渲染就基本完成了。
登录