这是一篇各处抄来的流水账
为什么ssr
ssr目的从来不是争论的焦点：SEO & 首屏加载时间
SEO很容易理解，全是一堆js，浏览器爬虫才懒得给你索引什么内容，关键也没有实际内容好索引o(╥﹏╥)o。
用沃尔玛的两张图解释一下首屏加载时间：
从图中可以看出，（这两种渲染方式的）区别主要在于出现首屏渲染的时机。对于SSR来说，服务器返回的是（结构相对完整的）HTML文件，（通过解析HTML文件），浏览器就能渲染出页面。而对CSR来说，浏览器拿到的只是包含JavaScript代码的HTML文件，（换句话，在浏览器渲开始渲染出页面之前，需要动态创建HTML标签）。这也就意味着，SSR可以让浏览器在边下载JavaScript文件的同时边渲染HTML页面，换句话说，浏览器再也不需要等到所有的JavaScript文件下载并执行完之后才去渲染页面啦。
这两张图应该清楚的说明了问题，如果csr，用户可能前面三个步骤看到的都是loading，ssr则是只有第一步骤白屏loading，对于一些电商类网站，快0.01s都是钱，应该不用多解释了。
同时，观察上面的过程，大家也可以注意到，ssr不代表完全在服务端渲染完所有，毕竟你的页面还是需要交互的，这些静态html打死也没法替你完成的，所以，把共同点也抄过来大家看下：
都需要下载React的
都需要经历虚拟DOM构建过程
都需要（给页面元素）绑定事件来增强页面的可交互性。
所以综合以上，大家应该也能对SSR利用场景有自己的判断：
- 需要seo的，上ssr
- 对首屏展示速度要求极高的，上ssr
- 后台admin看起来是必要性不大的
Vue SSR
1 vue怎么做ssr
vue-server-renderer 给你写好了，用它来把你的vue实例render成html，然后后端返回。
似乎一句话说完了，什么鬼？！！
首先，我们需要有一份同构代码，这部分代码和我们之前写的前端代码是基本一致的。然后，因为需要服务端渲染，所以服务端需要有一份同构代码打包后的js bundle，前端不必多说，天生需要一份。要注意的是，这两份是不同的bundle，因为server端和client端虽然都是做渲染工作，他们做的事情是有不同的，下面细说。然后经过中间的webpack打包后部署。接下来，请求到来，node server收到请求后，用server bundle作为入口拿到一份前端代码，render成html后返回给前端。前端收到后，就可以把预渲染的html展示给用户拉！！！就这么利索。但是前端还会去下载前端的bundle，然后以此为入口，激活后端返回的html，然后此时你的站点就完全可交互了！完美~
2 前后端的entry区别分析
理解两个entry的区别是理解SSR过程的关键，所以下面我们简单分析一下服务端和客户端分别做了什么：
- vue实例管理：
前端完全是独立的浏览器环境，所以只有一个vue实例，后端每个请求对应一个实例，所以entry返回的应该是一个实例生成方法，每次收到一个请求，就new 一个新的vue，执行render方法 - router 路由
前端路由，后端需要根据每个请求，获取一个新的router实例，然后通过请求path，找到目标访问组件，然后render这个组件即可！ - store 数据管理
server既然要渲染，一定要获取部分数据，然而在什么时候获取呢？很简单，router.ready后，此时我么已经知道需要走到哪个路由。还有个问题是，获取哪些数据呢？更粗暴，我们直接在每个路由对应的Vue组件里面写一个asyncData 方法，然后服务端拿到目标路由组建后，执行组件内的asyncData方法，获取到数据后，存到store里面，全部完成之后，带着store里的数据开始render，bingo，一个带着数据的html渲染好了！！！
不过这些数据前端也是需要，咋办呢，总不能再取一次吧？简单，用window带到前端，context.state 将作为 window.INITIAL_STATE 状态，自动嵌入到最终的 HTML 中。而在客户端，在挂载到应用程序之前，store 就应该获取到状态。 - 模板激活
后端render了一部分html回来，前端怎么用呢？这些总不能扔掉重新渲染吧，但是不扔掉，前端有需要将这些静态的html编程响应式的动态dom节点，咋办？激活他们！data-server-rendered="true" 后端渲染好的模板会带有这个属性，前端只要判断有这个属性，会尝试激活这些静态的html~
区别分析完了，相信大家对于SSR应该更糊涂了，别骂人，关掉网页，赶紧去看官方文档才是正道，这些辣鸡笔记只是我自己学习的时候随便写下来的，自己学到的，才是自己的，加油~~
