概念

服务器端渲染(Server-Side Rendering，SSR)指的是在服务器上完成网页渲染并将将其发送给客户端的过程。

为什么需要SSR?

SSR 发送给客户端的是包含了完整内容的网页，这样用户可以先看到网页的内容，而不需要等待“网页加载>执行JS>加载数据>渲染到网页”，从而提升用户体验。另一方面，因为网页内已经包含了具体内容，对搜索引擎也更加友好。

SSR的优势

SSR 能改善用户体验。
与传统服务器语言的对比很久之前，我们用 PHP 之类的语言输出 HTML，但是我们并不称其为”服务器端渲染”，因为现在的SSR 有更多的优化:

语言同构化:开发难度降低。
数据传递与状态管理:虽然还是 JSON，但框架尽量帮我们做好了。
渲染函数由边缘计算负责:更快的速度、
页面切换时不会重新加载-

与传统服务器语言的对比

很久之前，我们用PHP之类的语言输出HTML，但是我们并不称其为”服务器端渲染”，因为现在的服务器端渲染有更多的优:

语言同构化:开发难度降低。
数据传递与状态管理:虽然还是 JSON，但框架尽量帮我们做好了。
渲染函数由边缘计算负责:更快的速度、
页面切换时不会重新加载。

SSR的一般构成

当谈论服务器端渲染(SSR)时，一般构成包掊以下几个关键部分:

服务器端应用程序:这是运行在服务器上的应用程序，负责接收客户端请求，执行渲染过程，并返回渲染后的页面给客户端。
路由:服务器端应用程序需要能够根据客户端请求的不同路径，调用对应的渲染逻辑和数据获取方法。
模板引擎:用于将页面模板和数据结合，生成最终的 HTML 内容。我们目前会使用的模版引擎都基于某款 MVVM 框架。
数据获取:在渲染页面之前，服务器端应用程序通常需要获取页面所需的数据，这可能涉及到从
数据库、API或其他来源获取数据。
状态管理:在 SSR 应用中，需要考虑如何管理客户端和服务器端的状态同步，以避免出现不一致的情况。
客户端交互:尽管整个页面的初始渲染是在服务器端完成的，但在客户端加载后仍可能需要进行交互，如使用 JavaScript 添加动态内容或处理用户操作。

Nuxt3 的SSR 组件

对于大部分应用而言，服务器端渲染=加载数据+渲染HTML。所以理解 Nuxt3 里复杂加载数据的组件非常重要。

与异步组件
和useAsyncData useLazyAsyncData
useFetch和useLazyFetchi
用 process.client 和 <client-only>来处理仅限浏览器内部使用的功能
用 process.server 来处理仅限服务器使用的功能5
https:/nuxt.com/docs/getting-started/data-fetching#serializing-data-from-api-routes

Nuxt3 的渲染规则与缓存处理

Nuxt3 提供三种不同的渲染模式:

SSR:默认。即在服务器端渲染之后再发给客户端
ISR:部署后，渲染之后即保留缓存至下次渲染(渐进式渲染)
SWR:保留缓存，并在指定时间后校验缓存
prerender:部署时生成静态页面
https://nuxt.com/docs/guide/concepts/rendering!

如何鉴别用户身份

在 vue，或者说传统 SPA 里，所有请求都是后请求，即完成网页加载、JS 执行完毕后，再发起请求。这些请求，可以认为完全由开发者控制，即你知道什么时候该请求，然后发起请求。一般来说所有的请求都是数据交互类。

在 Nuxt 里，因为 SSR 的存在，所以请求至少可以分成两类:页面渲染类，数据交互类。前者会影响到 HTML 的内容。在网络环境里，存在大量缓存节点，假如跟用户相关的敏感数据渲染成HTML，缓存到 CDN 当中，会是非常大的安全问题。所以 Nuxt 在 SSR 及其内部发起请求时，不会携带 cookie;在用户主动发起的请求里，才会携带 cookie。官方文档 useRequestHeaders

如果要使用 localstorage 保存用户数据，则势必会存在两次渲染，请处理好loading 状态。