最近温习了一下SSR的基本过程和原理
SSR的常用场景：SEO优化，首屏渲染提速。
这两个理由在目前看来其实都不怎么充分，一来移动APP通常都不需要SEO，其次在首屏渲染在正确做好其余可做的优化，例如分包-CDN-缓存-骨架屏等等，通常不会是个大问题。
SSR的缺点： 工程复杂度增加，体现为
- 还要额外考虑容灾的fallback问题
- 往往需要新建项目，如果后端不是用Node写的，要求前端增加BFF 交互缺点，体现为
- 页面在水合hyration之前不可以交互
SSR的实现流程
以实际场景为例，要给首页增加SSR功能，需要用到哪些？ 假设服务器是express，那么需要引入react-dom/server， 由于现在的前端框架通常使用的都是前端路由，express针对任何路由只要返回index.html即可，这个是前端react生成的静态产物，返回index表示路由由前端负责处理。
那么对于SSR页面，就要返回另一个html，这里先称为ssr.html。
ssr内容怎么来，分为几部分
- body标签里的主要内容，需要和对应前端react组件里保持结构一致
- link和script标签里的内容，需要和index.html保持一致
假设有一个app.jsx文件，该文件在前端和后端都有一份，在服务端需要调用renderToString方法塞到ssr.html里
此外在前端调用hydrateRoot方法即可。
在绝大多数情况下，通常是先有了完整的CSR流程再考虑上SSR，这时候额外分出一个仓库即可。 新增仓库只需要处理单个SSR路由，服务端可以使用nextjs起一个全新的，然后再部署的时候在网关出进行分流即可 例如 xxx.com/index 请求走nextjs后端 xxx.com/detail 请求走原有的CSR后端
