SSR(服务端渲染)

用户请求服务器，服务器上直接生成 HTML 内容并返回给浏览器。也就是，服务端接收到请求后就在服务端将 HTML 页面生成好，然后将之返回给客户端，客户端拿到完整的 HTML 很快便能够将页面渲染出来，用户便能看到页面，与此同时，客户端也在拉取 JS 等其他资源，当 JS 拉取到本地并执行完后，页面就变得可交互了。

• CSR(客户端渲染)

  客户端渲染，页面初始加载的 HTML 页面中无网页展示内容，需要加载执行JavaScript 文件中的 React 代码，通过 JavaScript 渲染生成页面；同时，JavaScript 代码会完成页面交互事件的绑定，并且在本地执行 JS，获取JSON数据，然后渲染页面，渲染出的页面可以立即交互。

  对比CSR和SSR两种渲染方式可以看出，服务端渲染以客户看到页面为第一要务，也就是很多公司考核的首屏加载时间，交互可以放在次要的位置，另外的好处就是更有利于SEO。

  

• 直出

  直出说白了其实就是“服务端渲染并输出”，是服务端渲染的一种实现方案。但存在维护难度高，排查问题困难的问题，所以才有同构的实现方案出现。

• 同构

  • 同构的背景

    • SEO，浏览器异步渲染的数据大部分爬虫不支持，服务端同构渲染就不存在此问题

    • 渲染复杂，计算量大，首屏延迟或白屏严重，特别是低端手机

  同构这个概念存在于 Vue，React，Angular 这些MVVC的前端框架中，同构实际上是客户端渲染和服务器端渲染的整合。把页面的展示内容和交互写在一起，让代码执行两次。在服务器端（node环境）执行一次，用于实现服务器端渲染，在客户端再执行一次，用于接管页面交互。

  在 SSR 架构中，一般 Node 只是一个中间层，用来做 React 代码的服务器端渲染，而 Node 需要的数据通常由 API 服务器单独提供。这样做一是为了工程解耦，二也是为了规避 Node 服务器的一些计算性能问题。

  比较有名的同构框架：next.js/nust.js 。

  • 局限性

  react代码中不能存在直接操作DOM的代码，在node环境中会报错。

  服务器端路由和客户端路由代码有很大区别，无法公用。在服务器端需要通过请求路径，找到路由组件，而在客户端需通过浏览器中的网址，找到路由组件，是完全不同的两套机制，所以这部分代码是肯定无法公用。

  服务器端代码和客户端代码的打包也存在差异