什么是服务端渲染（SSR）？

　　假设有项目需要渲染一个首页，平时我们的项目启动后，开始渲染，请求页面，返回的body为空，然后执行js将html结构注入body中，再结合css来渲染样式，展现出来。

　　而使用了服务端渲染（SSR）后，简单理解是将组件或页面通过服务器生成html字符串，再发送到浏览器，最后将静态标记”混合”为客户端上完全交互的应用程序。渲染时请求页面，返回的body里已经存在服务器生成的html结构，之后只需要结合css显示出来。这就节省了访问时间和优化了资源的请求。

使用SSR后的优点？

　　1. 更利于网站的SEO

　　2. 更利于首屏页面的渲染

使用SSR后的局限性？

　　1. 服务端压力较大

　　本来是通过客户端完成渲染，现在统一到服务端node服务去做。尤其是高并发访问的情况，会大量占用服务端CPU资源。

　　2. 开发条件受限

　　在服务端渲染中，只会执行到componentDidMount之前的生命周期钩子，因此项目引用的第三方的库也不可用其它生命周期钩子，这对引用库的选择产生了很大的限制。

　　3. 学习成本相对较高

　　除了对本身项目使用的前端框架要熟悉，还需要掌握webpack、node、Koa2等相关技术。相对于客户端渲染，项目构建、部署过程更加复杂。

部分理解和思路：

　　next.js / nuxt.js 可以很好的完成SSR。

　　对于toB的项目，SSR无所谓，对于toC的项目，SSR还是必要的。

　　用了前端框架，浏览器接收到的还是模板和大量的JS，数据需要异步请求过来。所以存在SEO和性能问题。这时候就需要SSR了。

　　如果不使用服务器端渲染，一个页面的展示流程大概就是，浏览器先下载html和js，然后到服务器请求json数据，最后根据json生成页面。

　　如果使用服务器端渲染的话，以上步骤都在服务器端执行，也就是说服务器端从自己服务器那里先获取json，然后生成页面，最后把生成的页面输出成html给浏览器下载。