SSR 概述
服务器端渲染全称是：Server Side Render，在服务器端渲染页面，并将渲染好HTML返回给浏览器呈现。
SSR应用的页面是在服务端渲染的，用户每请求一个SSR页面都会先在服务端进行渲染，然后将渲染好的页面，返回给浏览器呈现。
构建SSR应用常见的库和框架有：Vue Nuxt, React Next.js等，SSR应用也称同构应用。
Nuxt：
优缺点
■SSR的优点
- 更快的首屏渲染速度
√浏览器显示静态页面的内容要比JavaScript动态生成的内容快得多。
√当用户访问首页时可立即返回静态页面内容，而不需要等待浏览器先加载完整个应用程序。 - 更好的SEO
√爬虫是最擅长爬取静态的HTML页面，服务器端直接返回一个静态的HTML给浏览器。
√这样有利于爬虫快速抓取网页内容，并编入索引，有利于SEO。 - SSR应用程序在Hydration之后依然可以保留Web应用程序的交互性。比如：前端路由、响应式数据、虚拟DOM等。
■SSR的缺点
- SSR通常需要对服务器进行更多API调用，以及在服务器端渲染需要消耗更多的服务器资源，成本高。
- 增加了一定的开发成本，用户需要关心哪些代码是运行在服务器端，哪些代码是运行在浏览器端。
- SSR配置站点的缓存通常会比SPA站点要复杂一点。
跨请求状态污染
- 在SPA中，整个生命周期中只有一个App对象实例或一个Router对象实例或一个Store对象实例都是可以的，因为每个用户在使用浏览器访问SPA应用时，应用模块都会重新初始化，这也是一种单例模式。
- 然而，在SSR环境下，App应用模块通常只在服务器启动时初始化一次。同一个应用模块会在多个服务器请求之间被复用，而我们的单例状态对象也一样，也会在多个请求之间被复用，比如：
- 当某个用户对共享的单例状态进行修改，那么这个状态可能会意外地泄露给另一个在请求的用户。
- 我们把这种情况称为：跨请求状态污染。
- 为了避免这种跨请求状态污染，SSR的解决方案是：
- 可以在每个请求中为整个应用创建一个全新的实例，包括后面的router和全局store等实例：
- 所以我们在创建App或路由或Stor对象时都是使用一个函数来创建，保证每个请求都会创建一个全新的实例。
- 这样的缺点就是需要消耗更多的服务器资源