本文目录一览：
五分钟了解 SPA 与 SSR
SPA（Single Page Application）即 单页面应用 。一般也称为 客户端渲染 （Client Side Render）， 简称 CSR。SPA 所需的资源，如 HTML、CSS 和 JS 等，会在一次请求中就加载完成。
SPA 有以下优点：
缺点是：
SSR（Server Side Render）即 服务端渲染 。一般也称为 多页面应用 （Mulpile Page Application），简称 MPA。
SSR 有以下优点：
缺点是：
vue项目改造SSR（服务端渲染）
缺点：1、SEO问题
2、首屏速度问题
3、消耗性能spa项目进行服务端渲染的问题
优点：
1、更好spa项目进行服务端渲染的 SEOspa项目进行服务端渲染，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面
2、首屏渲染速度快
SSR 简单来说就是将页面在服务端渲染完成后在客户端直接展示。
index.template.html
server.js
vue项目是通过虚拟 DOM来挂载到html的，所以对spa项目，爬虫才会只看到初始结构。虚拟 DOM，最终要通过一定的方法将其转换为真实 DOM。虚拟 DOM 也就是 JS 对象，整个服务端的渲染流程就是通过虚拟 DOM 的编译成完整的html来完成的。
需要通过Webpack打包生成两份bundle文件：
Client Bundle，给浏览器用。和纯Vue前端项目Bundle类似
Server Bundle，供服务端SSR使用，一个json文件
不管项目先前是什么样子，是否是使用vue-cli生成的。都会有这个构建改造过程。在构建改造这里会用到 vue-server-renderer 库，这里要注意的是 vue-server-renderer 版本要与Vue版本一样。
打包之后目录结构
vue.config.js
index.template.html
打包成客户端和服务器端
启动node服务
github地址：
现在又流行服务端渲染html了，这是为何？
1 一开始，html 就是后端渲染的。不过后端发现页面中的 js 好麻烦（虽然简单，但是坑多），于是让公司招聘专门写 js 的人，也就是前端
2 前端名义上是程序员，实际上就是在切图（CSS）和做特效(JS)，所以所有程序员中前端工资最低，职位也最低。所以前后端的鄙视链就出现了
3 nodejs 和前端 mvc 的兴起让前端变得复杂起来，前端发现翻身的机会，于是全力支持这两种技术，造成本不该做成 spa 的网站也成了 spa。慢慢地前后端分离运动从大公司开始兴起，目的就是前端脱离后端的指指点点，独立发展。（表面上是为了「代码分离」，实际上是为了「人员分离」，也就是「前后端分家」，前端不再附属于后端团队）
4 spa 之后发现 seo 问题很大，而且首屏渲染速度贼慢，但是自己选的路再难走也要走下去，于是用 nodejs 在服务端渲染这一条路被看成是一条出路
5 其实这是第二个翻身的机会，如果 nodejs 服务器渲染成为主流，其实就相当于前端把后端的大部分工作给抢了，工资压过普通后端指日可待
6 然而结果是 nodejs 服务端渲染始终是小众，因为后端也没那么脆弱，java php rails 十多年沉淀的技术岂是你说推翻就推翻的，已经运行多年的项目又岂是容你随便用 nodejs 重写的，另一方面 golang 等技术的兴起也给 nodejs 不少压力。最终只有少部分前端特别强势的团队成功用上了 Node.js 做渲染（比如阿里的一些团队），大部分公司依然是用 PHP 渲染 HTML。
7 于是 nodejs 退一步说好好好我不抢你们的工作，我只做中间层（大部分工作就是渲染页面和调用后台接口），绝不越雷池。后端说算你识相。现在 nodejs 主要搞什么微服务，也是为了抢后端还没注意的市场。
你要看一门技术的发展主要应该看背后的人是谁，应用场景是哪些，最后才是技术细节。
服务端渲染SSR之UmiJS预渲染
本文主要介绍 UmiJS 的预渲染功能。
服务端渲染（Server-Side Rendering），是指由 服务端 完成页面的 HTML 结构拼接的页面处理技术，发送到浏览器，然后为其绑定状态与事件，成为完全可交互页面的过程。
服务端渲染，首先得有后端服务器（一般是 Node.js）才可以使用，而没有后端服务器的情况下，可以使用 预渲染 。
预渲染与服务端渲染唯一的不同点在于 渲染时机 ，服务端渲染的时机是在用户访问时执行渲染（即实时渲染，数据一般是最新的），预渲染的时机是在项目构建时，当用户访问时，数据不一定是最新的（ 如果数据没有实时性，可以直接考虑预渲染 ）。
预渲染在构建时执行渲染，将渲染后的 HTML 片段生成静态 HTML 文件。无需使用 web 服务器实时动态编译 HTML，适用于 静态站点生成 。
Umi3 在 SSR 上做了大量优化及开发体验的提升，具有以下特性：
默认情况下，服务端渲染时关闭的，可通过配置开启：
服务端渲染的数据获取方式与 SPA(单页应用) 有所不同，为了让客户端和服务端都能获取到同一份数据，Umi 提供了页面级数据的预获取。
每个页面可能有单独的数据预获取逻辑，这里我们会获取页面组件上的 getInitialProps 静态方法，执行后将结果注入到该页面组件的 props 中，如：
getInitialProps 有几个固定参数：
为了结合数据流框架，我们提供了 modifyGetInitialPropsCtx 方法，由插件或应用来扩展 ctx 参数，以 dva 为例：
然后在页面中，可以获取到 store ：
同时也可以在自身应用中进行扩展：
同时可以使用 getInitialPropsCtx 将服务端参数扩展到 ctx 中，例如：
在使用的时候，就有 req 对象，不过需要注意的是，只在服务端执行时才有此参数：
则在执行 getInitialProps 方法时，除了以上两个固定参数外，还会获取到 title 和 store 参数。
关于 getInitialProps 执行逻辑和时机，需要注意：
执行 umi build ，除了正常的 umi.js 外，会多一个服务端文件： umi.server.js （相当于服务端入口文件）。然后在后端框架中，引用该文件：
render 方法参数和返回值如下：
完美兼容客户端动态加载，配置如下：
@umijs/preset-react 插件集中已内置对标题的渲染，通过以下步骤使用：
@umijs/preset-react 插件集中已内置 dva
这时候 getInitialProps(ctx) 中的 ctx 就会有 store 属性，可执行 dispatch ，并返回初始化数据。
Umi 同时支持对服务端和客户端包大小的分析
