SSR：首屏 HTML 在服务端渲染，直接返回完整页面。
单页面有个弊端就是首页加载可能会慢。因为他是所有资源（HTML、JS、CSS）需要一次性下载、解析并执行后才能渲染页面。
**使用ssr就可以解决这个问题，同时还能更好的seo优化，**搜索引擎爬虫可以直接看到完全渲染的页面。
使用 SSR 时还有一些权衡之处需要考量：
-
开发中的限制。浏览器端特定的代码只能在某些生命周期钩子中使用；一些外部库可能需要特殊处理才能在服务端渲染的应用中运行。
-
更多的与构建配置和部署相关的要求。服务端渲染的应用需要一个能让 Node.js 服务器运行的环境，不像完全静态的 SPA 那样可以部署在任意的静态文件服务器上。
-
更高的服务端负载，部署复杂、服务器压力大。在 Node.js 中渲染一个完整的应用要比仅仅托管静态文件更加占用 CPU 资源，因此如果你预期有高流量，请为相应的服务器负载做好准备，并采用合理的缓存策略。
应用的重要程度。例如，如果你正在在为你的应用使用 SSR 之前，你首先应该问自己是否真的需要它。这主要取决于首屏加载速度对开发一个内部的管理面板，初始加载时的那额外几百毫秒对你来说并不重要，这种情况下使用 SSR 就没有太多必要了。然而，在内容展示速度极其重要的场景下，SSR 可以尽可能地帮你实现最优的初始加载性能。
**SSG：**构建时将动态页面预先渲染为静态 HTML 文件的技术。它结合了 SPA 的开发体验与传统多页应用（MPA）的首屏性能优势，特别适合内容相对固定、对 SEO 和首屏速度要求高的场景（如博客、文档站、营销页等）。
✅ 优点：
|---------------------|-----------------------|
| 首屏速度极快 | HTML 直出，无需等待 JS 下载/执行 |
| 🔍 完美 SEO | 搜索引擎直接抓取完整 HTML 内容 |
| 🛡️ 高安全性 & 低成本 | 无服务器逻辑，可部署在 CDN，抗高并发 |
| 🌍 全球加速 | 静态文件天然适合 CDN 分发 |
❌ 缺点：
|---------------|---------------------------------------------------|
| 内容更新需重新构建 | 搭配 Headless CMS（如 Contentful） + Webhook 自动触发构建 |
| 不适合高度动态内容 | 混合渲染：关键页面 SSG + 动态部分 CSR（如评论区） |
| 路由必须提前知道 | 使用 nitro.prerender.crawlLinks: true（Nuxt）自动爬取链接 |
SSG vs SSR vs CSR比较
| 渲染方式 | 时机 | 特点 | 适用场景 |
|---|---|---|---|
| CSR（Client-Side Rendering） | 浏览器运行时 | 首屏慢、SEO 差 | 后台管理系统 |
| SSR（Server-Side Rendering） | 用户请求时 | 首屏快、SEO 好、服务器压力大 | 电商、新闻 |
| SSG（Static Site Generation） | 构建时 | ⭐ 首屏极快、SEO 好、零服务器压力 | 博客、文档、官网 |
如何选择？SSG vs SSR vs CSR
| 问题 | 选 SSG | 选 SSR | 选 CSR |
|---|---|---|---|
| 内容是否频繁变化？ | ❌（变化少） | ✅（实时） | ✅ |
| 是否需要 SEO？ | ✅ | ✅ | ❌ |
| 是否有用户登录态？ | ❌（公共页） | ✅ | ✅ |
| 能否接受构建时间？ | ✅ | ❌ | ✅ |