SSR
服务器端渲染（Server-Side Rendering，简称 SSR）是一种将 Web 应用程序在服务器端进行渲染的技术。在 SSR 中，服务器将应用程序的 HTML、CSS 和 JavaScript 等资源组装成一个完整的页面，并将页面发送给客户端进行展示。与客户端渲染（Client-Side Rendering，简称 CSR）相比，SSR 在服务器端完成了页面的渲染，减少了客户端的渲染工作量，提高了 Web 应用程序的性能和用户体验。
SSR 的优点包括：
- 更好的 SEO：搜索引擎可以更好地抓取服务器端渲染的内容，提高页面的排名。
- 更快的首屏加载速度：客户端不需要等待 JavaScript 加载和执行，从而提高页面的加载速度和用户体验。
- 更好的可访问性：在某些情况下，客户端无法访问某些资源，例如 JavaScript 文件，使用 SSR 可以确保这些资源被渲染到 HTML 中，从而提高 Web 应用程序的可访问性。
- 更好的代码复用性：可以将 SSR 渲染后的 HTML 直接用于客户端渲染，从而减少代码的重复开发。
- 更好的安全性：客户端无法访问服务器端的数据，从而提高了应用程序的安全性。
总之，SSR 可以提高 Web 应用程序的性能和用户体验，特别是在 SEO、首屏加载速度和可访问性等方面，具有显著的优势。
尽管 SSR 在某些方面具有优势，但也存在一些缺点，包括：
- 服务器端压力：在 SSR 中，服务器需要处理更多的请求，承担更多的渲染工作，从而增加了服务器的负担。
- 开发难度增加：SSR 需要同时考虑服务器端和客户端的代码，对开发人员的技能要求更高。
- 服务端渲染不利于实现动态交互：由于 SSR 的页面是在服务器端渲染的，因此无法在客户端实现一些需要动态交互的功能，例如某些复杂的动画效果等。
- 一些依赖于客户端的 JavaScript 功能可能无法使用：例如，某些特定的第三方库或插件可能无法在服务器端运行，因此无法在 SSR 中使用。
- 服务端渲染可能导致页面加载时间变长：由于 SSR 需要在服务器端完成渲染工作，因此可能导致页面加载时间变长，尤其是在访问服务器响应时间较长的情况下。
因此，在使用 SSR 时需要权衡其优点和缺点，根据具体的需求和场景来选择是否使用。对于某些特定的应用场景，可能需要采用其他的渲染方式，例如客户端渲染（CSR）或者预渲染（Prerendering）等。
CSR
CSR 模式是指客户端渲染模式，也称为前端渲染模式。在这种模式下，网页的渲染过程发生在客户端，即浏览器中，主要通过 JavaScript 来动态生成网页的内容。
在 CSR 模式下，浏览器向服务器请求一个 HTML 文件和一个或多个 JavaScript 文件，然后 JavaScript 代码在浏览器中运行，通过 DOM 操作动态生成页面结构，最终呈现在用户面前。
CSR 的优点包括：
- 更好的用户体验：由于客户端可以在本地快速生成页面，并通过 AJAX 等技术实现无刷新更新页面，所以用户可以更快地获取到页面内容，获得更好的交互体验。
- 更灵活的界面交互：由于在客户端进行渲染，开发者可以更灵活地实现动态交互效果、插件、组件等。
- 减轻服务器压力：由于大部分页面渲染工作都在客户端完成，服务器只需要提供 JSON 数据或 API 接口，减少了服务器的负载和带宽消耗。
- 更容易进行多端适配：同一个 API 可以用于多个平台，如 Web、移动端、桌面应用等，减少了开发成本和迭代时间。
- 更容易进行 SEO 优化：CSR 应用可以通过 SSR（服务端渲染）方式，将数据和 HTML 后端渲染输出给浏览器，以便搜索引擎抓取和索引。
CSR 的缺点包括：
- 首屏加载时间较长：由于需要先下载 JS 文件并执行，然后再开始请求数据并渲染页面，所以首屏加载时间会比较长。
- SEO 难度较大：由于 CSR 应用的 HTML 文件为空，搜索引擎需要等待 JavaScript 加载、执行和渲染完毕才能获取到页面内容，因此相对于 SSR 方式来说，SEO 难度更大。
- 对浏览器兼容性要求高：各种浏览器对 JavaScript 解析和性能支持程度不同，对于具有低配置的设备或老旧的浏览器，CSR 应用可能会出现较差的性能表现。
- 安全问题：由于部分页面逻辑在客户端进行处理，可能会存在安全漏洞。例如，恶意攻击者可以通过 XSS 攻击注入脚本，从而获取用户敏感信息或篡改页面内容。
- 对开发人员技术要求较高：相对于传统的后端渲染方式，CSR 应用需要前端工程师对前端框架、JavaScript 等知识掌握得更加深入才能更好地开发。
以上内容仅部分优缺点整理，欢迎指正！
