目录
什么是 SSR
Server-side rendering (SSR)是应用程序通过在服务器上显示网页而不是在浏览器中渲染的能力。服务器端向客户端发送一个完全渲染的页面（准确来说是仅仅是 html 页面）。同时，结合客户端的 JavaScript bundle 使得页面可以运行起来。与 SSR 相对的，还有一种 Client-side rendering（CSR）。CSR 和 SSR 的最大区别只是提供 rendering 的是客户端还是服务端，其本质还有一种东西。故以下如果没有着重提出 CSR 和 SSR 不一样的地方，则默认是一致的。
为什么要 SSR
得益于 react 等前端框架的发展，前后端分离，webpack 等编译工具的流行，以及 ajax 实现页面的局部刷新，使得我们现在的应用程序不再像曾经的应用程序一般需要从服务端获取页面，可以动态的修改局部的页面数据，避免页面频繁跳转影响用户体验等问题。也就是 SPA 越来越成为主流应用程序模型。但是 SPA 的使用，除了以上提到的优势以外，必然会带来劣势。譬如：
由于需要在页面加载之前就加载所有页面需要的 JavaScript 库，这使得首次打开页面所需要的时间比较久；需要研发专门针对于 SPA 的 Web 框架（各种具备 SSR 能力的框架，包括 Next.js 等）搜索引擎爬虫浏览器历史记录的问题（基于 pushState 的各种 router）为了解决上述提到的 1. 和 3. 的问题，SSR 开始登上历史的舞台。
SSR 怎么做
基于上述的理论，我们可以设计一个具有 SSR 功能的 React 框架。
首先，我们通过 create-react-app 命令初始化一个 React 项目，可以把初始化完成后的项目理解为具有最简单功能的项目。我们将基于该项目去实现一个 SSR 的功能。
# Yarn $ yarn create react-app ssr-demo同学们实践的时候需要注意，当前版本的 cra 命令新建项目的时候，启动会报类似于 Mini.... is not a function的问题。这是因为 mini-css-extract-plugin该插件版本更新导致的，只需要在 package.json里面通过 resolutions 限制mini-css-extract-plugin的版本为 2.4.5 即可生成项目的目录如下：
./ ├── README.md ├── build ├── node_modules ├── package.json ├── public ├── src └── yarn.lock已经自动安装完依赖，启动项目我们可以在「本地环境」看到一个最简单的页面。
接下来，我们去实现一个 SSR 功能。首先，我们需要安装 express（如果是 CSR 的话就不需要这一步）
yarn add express安装完成后，我们需要在 server/index.js文件中编写如下代码
import express from "express"; import serverRenderer from "./serverRenderer.js"; const PORT = 3000; const path = require("path"); const app = express(); const router = express.Router(); // 当爬虫的请求进来的时候，把所有请求导向 serverRenderer 路由 router.use("*", serverRenderer); app.use(router); app.listen(PORT, () => console.log(`listening on: ${PORT}`));其中serverRenderer该文件内容如下：
import React from "react"; import ReactdomServer from "react-dom/server"; import App from "../src/App"; const path = require("path"); const fs = require("fs"); export default (req, res, next) => { // 获取当前项目的 HTML 模板文件路径 const filePath = path.resolve(__dirname, "..", "build", "index.html"); // 读取该文件 fs.readFile(filePath, "utf8", (err, htmlData) => { if (err) { console.error("err", err); return res.status(404).end(); } // 借助 react-dom 依赖下的方法将 JSX 渲染成 HTML string const html = ReactDOMServer.renderToString(<App />); // 将 HTML string 替换到 root 中 return res.send( htmlData.replace(<div id="root"></div>, `<div id="root">${html}</div>`) ); }); };如上，我们完成了一个非常简单的具有 SSR 功能的服务端。但是仅仅如此是不够的，我们还需要在根目录下，新建parser.js将ESM 转成 CommonJS 运行起来，代码如下：
require("ignore-styles"); require("@babel/register")({ ignore: [/(node_modules)/], presets: ["@babel/preset-env", "@babel/preset-react"], }); require("./server");解释一下上面引入的包的作用：
@babel/register：该依赖会将 node 后续运行时所需要 require 进来的扩展名为 .es6、.es、.jsx、 .mjs 和 .js 的文件将由 Babel 自动转换。ignore-styles：该依赖也是一个 Babel 的钩子，主要用于在 Babel 编译的过程中忽略样式文件的导入。在经过上述的操作之后，我们先 yarn build出我们的产物，然后通过node parser.js来启动 SSR 服务。
经过上述的操作之后，我们设计出了一个非常简单的但合理的 SSR 服务端。作为对比，我们在这里简单的和 Next.js 做对比。
在 Next.js 项目的根目录中的 package.json 中，我们可以看到同样选择了 express 作为服务器.
... "eslint-plugin-react-hooks": "4.2.0", "execa": "2.0.3", "express": "4.17.0", "faker": "5.5.3", ...我们可以在 ~/packages/next/server/next.ts文件夹中，发现 Next.js会通过 createServer方法，启动一个 NextServer 对象，该对象负责启动服务器以及渲染模板模板。命令调用如下：
在 [Next.js](https://nextjs.org/docs/basic-features/pages#server-side-rendering)的官网中，我们可以看到其支持在页面通过 getServerSideProps函数，来实现动态获取接口数据。其实，在大多数支持 SSR 的框架库中，都有类似的设计。因为 SPA 的应用，难免需要通过服务端获取动态数据，并渲染页面，而实现渲染动态数据的 SSR 的设计思路都较为一致。即在该页面的组件同一文件中导出一固定方法，并且 return 某一固定格式。框架会将该数据用作初始数据对页面进行 SSR 渲染。
我们以Next.js为例，了解了 SSR 的大致设计思路，那么接下来我们了解一下 CSR 的大致思路.。
CSR 可以理解为阉割版的 SSR，只实现了 SSR 的预渲染功能。一般用于静态网站，不具备动态获取数据的功能。CSR 的渲染思路同 SSR 一致，不同点在于 SSR 是需要安装 express而 CSR 不需要安装 express。这也就导致了 CSR 和 SSR 在部署流程上的不同。SSR 项目如 Next.js应用在执行完 build 命令后，可以通过 start 命令执行启动服务器，不再需要配合 nginx 的反向代理。而 CSR 项目如 Umi仍然需要 nginx 的代理。
CSR 最大的不同点在于编译后产物的不同。通常一个前端项目在编译后的产物包括一下：
bundle.js或者 chunk.jsindex.htmlindex.csspublic/*其他相关文件，如 rss.xml等而具备 CSR 的项目通过编译后，会有更多的 HTML文件，这些文件的架构会按照路由生成。譬如：我们目前路由如下：
/a/b分别对应 ComponentA 和 ComponentB，那么在我们编译后产物中会生成a.html和b.html。在我们将产物部署到 nginx 服务上后，就可以实现预渲染功能。
要实现以上功能，最重要的步骤如下：
获取到当前项目的路由获取到路由对应的组件，如果组件未编译过，需要编译借助 react-dom 的能力将 JSX 渲染成 HTML，并插入到模板 HTML 中在编译后产物中根据路由创建文件夹，并将结果 HTML 生成到对应路径中到这里，我们了解了整个 SSR 的流程，相信大家对 SSR 都有了一定程度的了解。目前社区的绝大部分框架都不需要我们自行去做 SSR。我们了解渲染过程有助于我们在应对各种层出不穷的框架时，能够以不变应万变。