SSG vs SSR vs ISG 页面渲染策略对比

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

深入对比 SSG（静态生成）、SSR（服务端渲染）和 ISG（增量静态生成）三种页面渲染策略，涵盖以下维度：

• 性能表现（TTFB、可扩展性）
• 页面生成时机与触发机制
• 动态内容支持程度
• SEO 效果与用户体验
• 部署与运维复杂度
• 缓存机制与更新策略（含 stale-while-revalidate）
• 实际应用案例（如 Next.js、Nuxt、Vercel、电商/博客类场景）

SSG vs SSR vs ISG 页面渲染策略对比

静态站点生成（SSG）、服务端渲染（SSR）和增量静态生成（ISG，即 ISR：Incremental Static Regeneration）是当前 Web 开发中常见的三种页面渲染策略。它们在性能、动态内容支持、SEO、用户体验等方面各有优劣。下面将从 性能表现、页面生成时机、动态内容支持、SEO 友好度、用户体验、部署复杂度、缓存机制 和 常见应用案例 八个维度进行对比，并结合 Next.js、Nuxt、Astro 等主流框架或 Vercel、Netlify 平台提供实战参考。

三种渲染策略对比总览

下表汇总了 SSG、SSR 和 ISG 在各维度的核心差异：

维度	SSG（静态站点生成）	SSR（服务端渲染）	ISG（增量静态生成）
性能表现	TTFB 极低（CDN 静态文件分发）；渲染延迟最小；非常利于 CDN 缓存	TTFB 较高（每次请求服务器计算）；渲染延迟取决于服务器性能和数据获取；需合理缓存
页面生成时机	构建时生成所有页面（预渲染）；部署时一次性输出静态 HTML	请求时动态生成页面（按需渲染，每次请求都运行渲染逻辑）	混合：构建时预生成 + 请求时按需更新（设置过期/重建策略）
动态内容支持	对频繁更新或用户定制内容支持弱；所有用户看到相同静态内容	可根据请求提供个性化/最新数据（适合登录用户、实时数据）	一定程度支持动态更新：内容可定期或按需刷新，介于 SSG 与 SSR 之间
SEO 友好度	非常高：页面和 Meta 标签在构建时就嵌入，爬虫可直接抓取静态内容	非常高：每次请求返回完整 HTML 和 Meta，爬虫可抓取最新内容；性能略低但也有SEO优势	高：生成后相当于静态页，可抓取；内容更新有短暂滞后但整体SEO友好
用户体验	首屏渲染最快，毫无白屏；无额外数据等待；可能缺少个性化（需前端再注入）	首屏渲染较快但略晚于SSG（需等待服务器返回）；支持个性化无闪烁；交互需前端水合	首屏渲染接近静态页快速；首次增量生成时若使用加载占位可能出现短暂加载状态；随后无闪烁更新
部署复杂度	构建时间随页面数增长，站点大时构建较慢；部署简单（任何静态主机或 CDN）	构建主要打包代码，速度相对独立于页面数；但需服务器/函数环境运行，部署略复杂	初始构建比 SSG 更快（可跳过部分页面）；需支持后台生成机制（如服务器less函数），部署需平台支持
缓存机制	天生支持 CDN 全站缓存；页面不变则缓存永久有效	默认每次计算，不易直接缓存个性化内容；可配置HTTP缓存策略，但需权衡数据新鲜度	支持 stale-while-revalidate 模式：CDN 缓存页面并在失效时后台再生；兼顾性能和新鲜度
常见应用	内容固定的网站：博客、文档、营销页等；如 Next.js 静态页、Gatsby、Astro 等	实时变化或需个性化的平台：电商库存、新闻、社交内容、登录后台等；如 Next.js/Nuxt SSR	大型内容站点：电商目录、新闻资讯（需定期更新内容）；次热门长尾页面按需生成，如 Next.js ISR

接下来我们将针对每个维度展开详细分析。

性能表现（Performance）

• SSG（静态站点生成）：性能表现最优。所有页面在构建时已生成完毕，直接由静态文件服务器或 CDN 提供，首字节时间（TTFB）极低，通常仅耗费网络传输时间。由于无需服务器计算，页面响应和渲染延迟非常小，用户可迅速看到完整内容。静态文件易于缓存和分发，天然“CDN 友好”，可在全球节点快速命中缓存。此外，由于资源提前构建，避免了运行时的数据获取延迟，非常有利于提升核心性能指标和用户体验。总体来说，SSG 页面加载非常快，加载性能佳，这对 SEO 也有积极作用。

• SSR（服务端渲染）：相对而言性能略逊。每次请求都需服务器现算出页面，TTFB 明显高于 SSG。服务器端渲染过程包括获取数据、模板拼接等，如果后台 API 慢也会拖延整个页面响应。因此 SSR 页面初次字节时间和渲染延迟往往较大，尤其在高并发时服务器负载上升可能导致响应变慢。虽然通过SSR获取到了最新数据，但性能开销是以牺牲速度换取动态性。同时，为改善性能可以结合缓存策略：例如针对不经常变动的SSR页面设置 CDN 缓存或服务器缓存，但这需要开发者自行实现。一些新技术（如Edge SSR）将渲染移至边缘节点，可降低网络延迟，但仍无法比拟完全静态化的速度。

• ISG（增量静态生成）：性能介于两者之间。对于已生成或缓存的页面，ISG 和 SSG 一样能以静态文件速度响应，TTFB 非常小；对于过期需更新的页面，第一次请求会触发重新生成，此次响应会变慢，相当于执行了一次SSR渲染。不过通常可通过stale-while-revalidate机制优化用户体验：即在页面过期时先仍然快速返回旧静态页面，然后后台异步再生成新页面。这样用户几乎总能快速拿到页面（哪怕内容稍旧），而内容很快在后台更新后，后续用户将享受更新后的静态页面。总体而言，大多数请求下 ISG 的性能接近 SSG（高缓存命中率），只有在内容刚失效需要重建时性能暂时下降。通过合理设置 revalidate 时间（如 Next.js getStaticProps 中的 revalidate 参数）可以在性能和数据新鲜度间取得平衡。例如 Next.js 的 ISR 允许开发者设定页面静态有效期，期间请求走缓存，非常快，超过期限才触发再生。需要注意的是，ISR 技术通常依赖框架/平台支持（如 Vercel 平台会为 ISR 自动生成对应的无服务器函数来处理再生成），在支持良好的平台上其性能优势才能充分发挥。

页面生成时机（Timing of Generation）

• SSG – 构建时生成：采用 预渲染 策略，所有页面 HTML 在构建阶段一次性生成。也就是说，在部署或发布时运行构建脚本，把可能的页面组合都输出为静态文件。例如使用 Next.js 的静态导出或 getStaticProps 在编译时抓取数据生成 HTML，Nuxt 通过 nuxi generate 预渲染页面。优点是请求发生前页面已准备就绪，用户访问时无需计算即可得到页面。缺点是构建时机早于请求，页面内容与数据源的同步取决于构建频率：一旦构建完成部署上线，后续内容变更不会自动反映，除非再次触发构建。由于构建发生在发布阶段，每次更新内容通常需要重新构建整个站点并部署。因此，小型站点影响不大，但当页面数量庞大或构建耗时长时，频繁重建会成为瓶颈。

• SSR – 请求时生成：采用 按需渲染 策略，页面 HTML 在每个请求到来时动态生成。也就是浏览器发起请求后，服务器端即时获取最新数据、拼接模板，生成完整HTML后返回。例如 Next.js 中使用 getServerSideProps 实现 SSR（每次请求触发函数运行），Nuxt 作为默认模式则在 Node 服务端渲染页面。优点：渲染时机紧随请求，意味着每次都可使用最新数据，无需预先构建，数据变化能够立即反映到页面。缺点：每个请求都要耗时渲染，服务器承担持续的渲染负载。此外，SSR 渲染过程才能拿到请求上下文（如用户cookie、查询参数等），这虽然是其优势（支持个性化），但也意味着必须有服务器环境持续运行，无法像纯静态站点那样简单部署到CDN存储。

• ISG – 混合生成：采用 构建时 + 请求时混合 的策略。增量静态生成本质在 SSG 基础上增加按需更新能力。一般有两种模式：

  1. 定期失效再生成：在构建时先生成初始静态页面，并为每个页面设置一个重新生成周期（如 60 秒）。页面部署后的一段时间内都直接使用已生成的静态文件响应请求；一旦超过设定时间，下一个请求到来时触发该页面的重新渲染（可能阻塞该请求或后台异步进行），然后更新静态文件缓存。这样实现增量更新，而不需每次都重建所有页面。
  2. 按需触发更新：有些框架支持通过API手动触发某些页面的重新生成。例如 Next.js 提供了 res.revalidate() 接口，允许从CMS或管理后台在内容更新时通知前端应用去刷新特定页面缓存。这也是混合模式的一种，实现 细粒度控制页面生成时机。

  ISG 的生成时机因此是首次构建 + 后续按设定或需要再生成。开发者可以预渲染大部分重要页面，同时对变化频繁或数量巨大的页面选择跳过构建、在用户首次请求时再生成（Next.js 中 fallback 设置为 true/blocking 就是这种机制）。总的来说，ISG 提供了构建时和请求时的折中方案：常见做法是「热点内容预先静态生成，长尾内容或频繁更新内容使用按需生成/更新」，从而降低初始构建压力，又保证大部分页面快速提供。

对动态内容的支持程度

• SSG：对动态数据和个性化内容支持有限。由于页面在构建时已经生成完毕，所有用户看到相同的静态内容，无法针对每个请求定制。这意味着涉及登录用户的个人信息（如“欢迎你，Alice”）、个性化推荐、实时更新（股票行情、实时聊天）等场景，纯 SSG 无法直接实现。如果尝试在纯静态页面中支持这些动态内容，通常需要依赖客户端脚本在浏览器中执行（例如用户登录后由前端再获取个人数据插入页面），这可能导致加载后的内容闪动或延迟出现，影响体验。因此，SSG 适用于所有用户内容相同且不频繁变化的场景，如博客文章、文档页面等。对频繁变动的数据（如电商产品库存、新闻头条）或需要实时性的功能，SSG 并不适用。正如一些经验所指出：“SSG 适用于每个用户都一样且内容不常变动的静态内容；SSR 则用于需要个性化或经常更新的数据”。

• SSR：对动态内容支持最强。由于每次请求都在服务端生成页面，可以利用请求信息生成差异化内容。这让 SSR 非常适合需要个性化和实时数据的场景。典型例子：登录用户页面可以通过 SSR 根据用户会话返回专属内容（如用户姓名、通知）而无需前端等待；个性化推荐（如因人而异的商品推荐流）可在服务端根据用户画像生成后直接嵌入 HTML；实时数据（如最新的股票价格、社交动态）每次请求都可拉取当前最新的数据呈现。SSR 天然支持读取 cookies、请求参数等上下文，因此在多语言站点（根据请求头返回对应语言内容）或 A/B 测试（根据用户属性返回不同版本页面）中也很有用。总的来说，SSR 能确保用户每次获取到最新、定制的页面内容。需要注意的是，如果不结合缓存，SSR 每次都查实时数据，尽管新鲜但可能加大后端压力。不过对于不需要给搜索引擎抓取的登录后应用，SSR 能在不牺牲SEO的前提下提升用户获取动态数据的体验。

• ISG：对动态内容提供了一定程度支持，试图在“内容新鲜”与“性能稳定”之间取得平衡。ISG 的思想是允许页面的部分动态内容以增量方式更新：绝大多数时间用户看到的是缓存的静态内容，但后台会定期重新获取数据并更新页面。这样对于不需要秒级实时更新但又要求定期刷新的内容很合适。例如新闻网站一天内文章不会改变但每天新增，使用 SSG 可静态化文章页面，而主页新闻列表可设定每隔几分钟用 ISR 刷新一次，使新文章自动呈现出来。再如电商商品页，商品描述等相对静态而库存/价格等数据可每隔一段时间更新，这可以通过 ISR 周期再生成或者在用户请求该页时如检测已过期则重新生成获取新库存价格。但是，ISR 仍然不适用于真正实时性要求极高或强用户定制的场景，因为在静态页面过期之前用户可能会看到过期的数据。例如价格在短时间内多次波动，ISR 即使设很短间隔仍可能给部分用户呈现旧价格（有一个“过期窗口”）；或者用户私人数据（ISR 针对URL缓存，对不同用户不会区分缓存），所以无法给不同登录用户提供不同内容——这类情况仍需要 SSR 或在客户端解决。概括来说，ISG 适合内容更新频率适中、对新鲜度要求较高但不至于要求每秒同步的场景，它通过定期再生让静态页面“追上”动态数据，同时保持大部分时间的高性能静态输出。

SEO 友好度（可爬取性与 Meta 注入）

• SSG：对 SEO 非常友好。由于所有页面在构建时已经生成完整 HTML，包含页面内容和 <meta> 等标签，搜索引擎爬虫可以直接抓取页面的静态内容，无需执行任何脚本就能获取完整信息。这解决了单页应用 CSR 的爬取难题。并且因为 SSG 页面加载速度极快，这对提升SEO排名也有帮助——搜索引擎更偏好快速、响应迅速的站点。常见的静态站点生成框架（如 Gatsby、Hexo、Docusaurus、VuePress 等）都以良好的 SEO 表现著称。需要注意的是，如果站点内容更新后没有及时重新构建部署，爬虫在此期间看到的可能是旧内容。但对于内容相对稳定的网站（博客文章等），SSG 提供了可爬取性和性能的双重优势：既能让爬虫抓到有用信息，又因纯静态页面速度快而获得搜索引擎的性能加分。

• SSR：同样对 SEO 非常有利。SSR 的页面在服务端渲染完成后再送出，爬虫收到请求响应时也能直接获得完整的 HTML 内容和元数据。因此 SSR 和 SSG 在页面可爬取性上几乎没有差别，二者都比纯前端渲染更易被搜索引擎索引。SSR 相比 SSG 的一个优势在于：由于每次请求都生成页面，内容和 Meta 标签始终是最新的。例如，如果某商品页面的描述或标题频繁变化，SSR 确保爬虫每次抓取都看到最新的 Meta 信息，不存在“构建后变更未部署”的窗口期。不过需要权衡的是 SSR 页面通常响应速度较静态略慢，而加载速度本身也是影响 SEO 排名的因素之一。总体而言，在搜索引擎眼中，SSR 与 SSG 都属于预渲染内容，SEO 表现一流。正如 Next.js 官方所总结的：最重要的是页面数据和元数据在加载时已就绪，无需JavaScript，这种情况下 SSG 或 SSR 都是最佳选择。

• ISG：增量静态生成在 SEO 角度与 SSG 几乎相当。因为对于访问者（包括爬虫）来说，ISG 页面在大部分时间都作为静态页面提供，爬虫抓取到的就是预渲染好的 HTML 和 Meta 标签。这意味着可爬取性没有问题，搜索引擎同样能索引页面内容。并且借助 ISR，我们可以针对SEO需求灵活更新页面：例如定时再生成可以确保每日的新内容出现在页面上被爬虫看到，而无需人工触发部署。需要关注的是，如果使用了 Next.js 的 ISR “fallback”模式（即未预先生成的页面，用户第一次访问时会先看到一个占位符或加载中），那么爬虫第一次来抓取时可能碰巧得到的是一个空内容的占位页，这对SEO不利。因此在实践中，应确保重要的SEO页面要么提前静态生成，要么使用“blocking”模式（首次访问等待生成完再返回），避免爬虫收到不完整内容。总体来说，ISG 保留了静态页面SEO友好的特性，又允许内容更新，对需要频繁更新内容以提升SEO效果的网站（如新闻、博客）非常适用——例如使用 Next.js ISR，可以无需全站重构就更新页面内容，有利于搜索引擎抓取最新的信息。

用户体验（首屏速度、闪屏与加载策略）

• SSG：能够提供极佳的首屏加载体验。因为页面是静态的，浏览器请求后几乎立即收到完整HTML，首屏内容可以迅速呈现。用户不会看到白屏或长时间的加载指示，感知性能很好。同时，由于资源都已在构建时确定，页面往往可以无额外数据请求就完整渲染出来。这减少了前端等待数据的时间。此外，SSG 页面通常搭配框架的静态水合（hydration）：页面加载时已包含内容，随后加载少量 JS 将页面变为可交互状态。用户视觉上几乎感觉不到等待，只是在尝试交互时，可能需要等脚本加载完绑定事件。但因为SSG页面初始就有内容，所以不会出现闪烁。唯一需要注意的是，当涉及用户个性化内容时，SSG 可能使用通用占位符。比如未登录用户看到“请登录”按钮，登录后客户端脚本替换为用户名，这种情况下用户可能在页面加载后瞬间看到内容改变（从占位符变成个性化信息）。这是一种“闪变”，但通常影响不大且可以接受。总体来说，对公开内容的首屏渲染，SSG 提供了最快速且稳定的体验。

• SSR：在用户体验上也表现良好，但略有折衷。优势在于首屏同样是完整内容：因为SSR直接返回渲染后的HTML，用户打开页面时就能看到排好版的内容，不会像纯CSR那样白屏等待。因此 SSR 首屏体验和SSG一样，没有大块空白。但是，由于SSR需要服务端计算，用户初次请求等待时间比SSG稍长一些（通常慢几十毫秒到几百毫秒，取决于服务器速度）。对于简单页面感知不明显，但在网络或服务器较慢时，SSR页面可能感觉“首屏加载稍晚于静态页”。不过，一旦HTML抵达浏览器，后续互动体验与SSG类似：框架会进行水合，将页面变为可交互应用。SSR 的一大优点是没有前端数据占位的闪烁：所有该显示的数据服务器都已插入，比如用户已登录则页面直接显示用户名，不会像SSG那样先显示“登录”再变“欢迎，用户名”。因此对需要个性化的页面，SSR 用户体验更加平滑。一些SSR框架还支持流式渲染和部分水合，可以进一步提升感知速度（例如 React 18+ 下 Next.js 支持流式传输HTML，边生成边发送）。总结而言，SSR 为用户提供了内容完整的首屏，稍微牺牲了一点首字节延迟，以换取动态和个性化——对于需要这些特性的场景，用户往往更愿意接受略微的等待。

• ISG：用户体验大体接近 SSG，但需要考虑第一次加载的策略。对于已经生成好的页面，ISR 页面与普通静态页面无异，用户首屏极快，没有白屏和闪烁。对于那些尚未生成或已过期需要刷新内容的页面，框架提供了不同加载策略：

  • 阻塞式（如 Next.js fallback: 'blocking'）：首次有人请求某页面且需要增量生成时，服务器让请求等待直到生成完成再返回。用户会稍晚看到页面（相当于这次用了SSR生成），但好处是拿到的就是完整内容，不存在中途内容替换，体验和SSR类似。
  • 非阻塞式（如 fallback: true）：首次请求时立即返回一个基本结构或加载指示，然后在服务器后台异步生成真实页面。用户立即看到的是一个Loading状态或骨架屏，这总比白屏好，但仍需要在几秒内自动替换为最终内容。当生成完毕后，浏览器接收到新数据渲染出完整页面内容，用户会感觉内容“突然出现”或从加载状态切换，这其实是一种闪屏（内容从空白/骨架变为真实内容）。这种策略确保首次响应快，但体验上不如直接等待完整内容。
  • 旧内容回退（stale-while-revalidate策略）：如果页面已存在过期的缓存版本，可以立即把旧版本发给用户（几乎无延迟，用户有内容可看），同时后台获取新数据并更新页面。用户当下看到的是旧内容，但页面很快静默更新（一般下次请求或通过客户端刷新后可见新内容）。这种方式避免了完全的加载等待，除非旧内容差异很大，一般用户察觉不到正在更新。

  综合而言，ISG 的用户体验在99%情况下和SSG一样出色（因为绝大多数页面都会提前生成好并缓存命中）。只有在缓存未命中或内容刷新的瞬间，才存在体验权衡：要么让用户稍等（阻塞式），要么先给一个loading再替换（非阻塞式）。在Next.js实践中，开发者通常会对重要页面采用阻塞式以保证SEO和体验，对次要长尾页面用非阻塞提升首字节速度。得益于这种灵活性，用户平时并不会感到区别——他们大多享受着近似静态站点的快速加载，同时网站的内容还能保持相对新鲜而避免长时间不更新。

部署复杂度（Build & Deployment Complexity）

• SSG：部署相对简单，但构建耗时可能较长。SSG 生成的是纯静态文件，部署时只需将HTML、CSS、JS等文件上传到静态服务器或 CDN 即可，无需专门的应用服务器。因此平台兼容性很好：任意静态托管（GitHub Pages、Netlify、Vercel、OSS等）都可胜任。而且静态文件不依赖特定运行环境，运维开销低。这也是 JAMstack 流行的原因之一。但是，SSG 构建过程本身可能很重：当站点页面数成千上万时，构建全部页面会耗费显著时间和资源。每次微小改动（如修正一个字）可能都需要完全重新构建和部署整个站点。对于大型内容站点，这会影响 CI/CD 的效率。为缓解这一问题，很多框架和平台提供了增量构建或并行构建支持。例如 Gatsby 引入了增量编译，11ty 等也有部分更新的能力。但这些机制实现复杂，通常也需要CI流水线支持。总体来说，小型SSG项目部署非常简单轻松；大型SSG项目则要考虑构建优化（如按区域拆分、多进程并发、使用缓存等）以确保部署不会过慢。

• SSR：部署和基础设施要求更高。因为 SSR 需要在服务器运行代码来生成HTML，所以部署时需要提供运行环境。最常见是在 Node.js 服务器或无服务器函数（Serverless）上部署应用。例如 Next.js SSR 可在 Vercel 以 Serverless Functions 形式自动部署，也可在自己的 Node 服务器上运行一个常驻进程处理请求。相对SSG，部署SSR有几点复杂性：

  1. 环境依赖：需要保证服务器有正确的运行时，如 Node.js 版本、支持的内存/CPU。同样代码在本地跑没问题，但部署到云函数可能有冷启动、超时等限制，需要调优。
  2. 状态管理：因为有服务器，需处理应用的状态、日志、错误监控等，比静态托管更多 DevOps 考量。如 Nuxt 部署到 Node，要配置负载均衡、多实例等等。
  3. CI/CD：SSR 应用的CI主要是编译和自动测试，与前端框架本身类似，速度通常不受页面多少影响（因为不预生成所有页面）。但需要测试服务端渲染输出正确性，而不像SSG那样所见即所得文件容易验证。
  4. 兼容性：部分平台对 SSR 支持需额外配置。例如 Netlify 默认是静态部署，但提供了 Functions 来运行 SSR，需要使用官方插件（如 netlify-plugin-nextjs）才能支持 Next SSR/ISR。在 Vercel 上，Next SSR 则被无缝支持，因为 Vercel 为Next优化了部署流程，包括自动拆分函数和缓存。

  此外，SSR 部署后维护也更复杂：因为有长时间运行的服务，要关注扩展性（流量高时添增实例或启用CDN缓存）、安全（防止服务器攻击）等。但换个角度，像 Vercel 这样的无服务器平台已经将这些复杂度封装得很好，开发者几乎像部署静态站点一样就部署了SSR应用。总之，SSR 在部署上需要更多后端/serverops知识，不过现代框架和平台降低了门槛。

• ISG：部署复杂度介于二者之间，更偏向 SSR 的要求。增量静态生成虽然最终提供静态文件给用户，但实时再生阶段需要后台逻辑支持。以 Next.js 的 ISR 为例，部署时实际上会为具有 ISR 的页面生成特殊的服务器函数，用于在请求触发时重新获取数据、更新静态文件缓存。因此必须部署在支持这些函数的平台。目前最成熟的是 Vercel 平台：其原生支持 ISR，无需额外配置；Netlify 也通过插件支持 Next.js ISR（利用 Netlify Functions 实现类似效果）。如果自行部署 Next.js 应用到 Node服务器上，ISR 也能工作，但需要确保文件系统可读写和有调度逻辑。相比纯SSR，ISG 除了基本的服务器运行外，还涉及缓存失效机制的配置管理，这增加了一定复杂度。例如你需要设置好 revalidate 时间、确保数据库或CMS内容更新能通知前端重新生成等等。在 CI/CD 方面，ISG 初始构建时间更短（因为许多页面选择不预生成），这对持续部署是利好。但相应地，上线后第一批用户访问某些页面时可能经历稍慢的生成过程（需要在产品上做好预期管理或预热）。综上，ISG 部署对于平台有一定要求，不过像 Next.js + Vercel 这样的一站式方案已让开发者无需深究内部复杂度，只要按照框架约定开发即可。相较 SSR 手工优化缓存，ISG 更像是框架帮你做了这件事，所以开发部署流程对开发者较友好，但实现细节在平台端较复杂。

缓存机制与策略

• SSG：静态站点天生与缓存契合。由于生成的页面永远不会主动变（除非重新部署），我们可以将其当做纯静态资源长期缓存。例如配置 CDN 对 HTML 设置长时间 Cache-Control，甚至把整个站点文件部署到各地 CDN 节点，用户每次请求都直接从最近节点获取文件，几乎无延迟。如果内容需要更新，只能通过重新部署新的文件来“更新缓存”（因此SSG站点通常使用版本化文件名或每次部署时让文件路径变化，以使CDN拉取新文件）。浏览器端也可安全地对静态资源使用 aggressive caching 策略。SSG 无需考虑缓存过期问题，因为内容不更新就一直有效。这也是为什么SSG 可以轻松利用 CDN 提升性能和扩展性的原因：所有页面当作静态资产分发，缓存命中率100%。开发者几乎不用写任何代码来管理缓存逻辑——部署即缓存。这一点在多服务器横跨式部署时尤其有优势，静态文件可以在多节点分发存储，扩展非常容易。

• SSR：服务器渲染需要更慎重地对待缓存。默认情况下，SSR 每次都重新生成页面，意味每次都是新内容。然而如果某些页面数据并非每次都变，比如一个公开新闻页在发布后几分钟内容不变，我们希望缓存以减少服务器压力。这就需要手动设计缓存策略。常见做法：

  • HTTP 层缓存：通过设置HTTP头（如 Cache-Control: s-maxage=60, stale-while-revalidate=300）使CDN或代理服务器缓存SSR响应。在 Next.js 中，可以在 getServerSideProps 的返回中设置props之外的revalidate，或直接使用 App Router 中的 fetch 缓存机制，让框架帮忙加缓存头。这样CDN会在短时间内缓存页面，后续请求直接命中缓存。但对个性化页面不适用，因为不同用户不该共用缓存。
  • 应用层缓存：在服务器代码中自行缓存某些数据或HTML。例如缓存数据库查询结果5分钟，用户请求先查缓存，没有再真正查询。这对减少后台API压力有效果。
  • 分段缓存：使用 Edge Side Includes 或类似技术，把页面拆分成可缓存和不可缓存部分。比如页面大部分静态，可缓存一天，小部分用户相关不缓存。这需要更复杂的架构支持。

  总体而言，SSR 能实现和 SSG 接近的缓存效率，但需开发者精心配置。很多情况下出于简化，SSR 页面选择不缓存（确保每次最新），代价是性能和服务器压力。如果使用像 Vercel 这样的无服务器平台，它本身会对 SSR 函数提供一些缓存能力（比如最近几次响应在边缘缓存几秒）。但开发者仍应明确哪些页面或API可以缓存以充分利用CDN。值得一提的是，SSR 的缓存策略一旦配置失误，可能导致陈旧内容被用户或爬虫看到，这就丧失了SSR的初衷。因此对于金融、交易等实时要求高的场景通常宁可不缓存以保证实时性。

• ISG：增量静态生成可以看作是框架层面实现的智能缓存。它利用静态文件缓存结合失效再生策略，实现了类似 HTTP stale-while-revalidate 的效果：页面在过期前由 CDN 持续缓存，过期后第一次请求触发后台更新，同时旧页面可以继续服务一段时间。以 Next.js 为例，开发者在 getStaticProps 中设置 revalidate 秒数后，框架会自动：

  1. 将页面部署到 CDN，初始状态和普通 SSG 相同，CDN 按静态文件处理。
  2. CDN 在revalidate时间内都直接返回缓存页面，所有用户看到一致内容。
  3. 超过该时间后，下一次请求来到CDN，因为过期CDN可选择将请求转发给Origin函数。Origin（无服务器函数）会重新生成页面并将新页面输出，同时更新CDN缓存。
  4. 新页面生成成功后，后续请求都得到更新后的页面。如果生成失败，则延长旧页面缓存（防止服务中断）。

  这个流程确保了高命中缓存 + 自动失效更新。对于用户而言，他们几乎总能从CDN获得页面（即使过期也可能拿到上一个版本作为备用），因此体验平稳。而对于开发者，不必手写缓存逻辑，框架帮忙处理了“何时失效、何时刷新”。此外，Next.js 还支持按需重新验证（On-Demand Revalidation）：通过访问一个特定API路径，让服务器立即废弃某页缓存并重建，用于内容管理员主动刷新。这在需要即时更新时非常有用（如CMS编辑发布文章后调用该接口刷新页面）。需要注意的是，ISG 对平台要求较高：如果纯静态主机不具备运行再生成逻辑，就无法实现真正的 ISR。所以使用ISR时通常选择支持它的托管（Vercel、Netlify 等）。整体看，ISG 将缓存机制提升到了应用层，让开发者以声明式配置获取类似CDN缓存的好处，又不失控于过期内容问题，是现代框架非常重要的特性之一。

常见应用案例与实战参考

SSG 应用案例：适用于内容相对固定、无需频繁更新的网站。例如：

• 技术文档、博客：典型案例是使用静态站点生成框架构建文档或博客，如使用 Next.js 的静态导出、Docusaurus、VuePress 等。这类内容发布后很少更改，或者可以接受定期批量发布，SSG可生成高度优化的静态页面，读取速度飞快。
• 企业官网、营销落地页：这些页面强调加载性能和SEO，内容改动可通过重新部署发布。使用 SSG（甚至手工编写静态页）可以最大化利用CDN加速，保障全球快速打开。
• 产品目录、展示型网站：如一个摄影作品集网站，作品条目有限且不常改动，SSG让每个作品页面都提前渲染好图文，提高首次加载速度和离线可用性。

在实战中，框架 Astro 就以优异的静态生成和部分水合能力闻名，非常适合上述场景。Astro 默认构建为静态HTML，并只对互动组件执行必要的JS，这意味着它生成的站点初始渲染极快、JS负载极小，用户体验接近原生静态页面。很多团队用 Astro 搭配 Markdown 或 CMS 构建博客文档，既享受了SSG性能，又能在需要时插入动态组件。此外，React 的 Gatsby、Vue 的 Nuxt (静态模式) 也常用于内容站点，如 Gatsby 用于博客和营销网站、Nuxt generate 用于文档门户等。

SSR 应用案例：适用于需要实时数据或个性化内容的网站。例如：

• 电商网站：在线商店需要展示实时的库存、价格变动、个性化的推荐商品等。SSR 能确保用户每次打开产品页时看到最新的库存和价格，购物车等也可基于用户会话渲染。此外，许多电商站点有海量商品，如果纯SSG生成会非常庞大难以管理，因此倾向于SSR动态获取数据。Nuxt.js 和 Next.js 都被广泛用于电商网站的服务端渲染，以实现SEO友好的同时提供动态功能。据实践经验，Serverless SSR（如 Vercel 平台）可让中小型电商站点按需扩展，避免维护繁重的后台服务器。
• 新闻、实时资讯门户：新闻站点要求搜索引擎能及时索引新发布的文章，同时访客应当看到最新的内容。SSR 用于主页和频道页可以在请求时获取当前最新文章列表。比如 Next.js 官方博客提到，如果数据更新非常频繁且需要即时呈现，SSR 会比预生成更合适。一些媒体网站使用 Node.js SSR 或采用Next.js的新 App Router 流式渲染，以获得最新内容和良好SEO。
• 社交媒体、互动应用：这类应用通常需要根据用户登录状态和关系网显示不同信息（动态、消息通知等）。由于SEO对登录后内容无关紧要，这些内部页面有时直接用CSR（如SPA）即可。但是为了优化首屏加载和分享展示，很多社交平台会对公开内容使用SSR。例如Twitter最初就是SSR，让未登录用户或爬虫可以看到完整用户主页内容。Facebook的Feed对登录用户也是SSR首屏然后客户端接管。总之，SSR 在需要高度动态但仍想改善首屏体验的web应用中是一种折中方案。
• 数据仪表盘、管理后台：对于企业内部仪表盘或管理界面，SEO不重要但首屏性能和数据实时性很重要。SSR 可以在用户打开页面时就加载好关键数据（避免白屏等），提升专业用户体验。比如一些监控系统面板用Next.js SSR预取数据，这样运维人员打开页面立刻看到图表，无需手动刷新。当然，也有方案是纯CSR配合缓存，但SSR能减少手动等待步骤。

在实战中，Next.js 和 Nuxt.js 是 SSR 场景的主力框架。Next.js 允许开发者在每个页面选择使用 SSR (getServerSideProps) 来获取数据，结合 React 生态构建复杂交互。Nuxt.js 则提供了开箱即用的 SSR 渲染，在 Vue 世界中被广泛用于上述场景。此外，一些传统服务器模板引擎（如基于Laravel、Django的服务器渲染）在SSR策略上类似，仍然大量应用于需要服务端动态输出HTML的项目。部署方面，Vercel 平台因对 Next.js SSR 的优异支持成为许多团队的选择，一键即可部署全球加速的 SSR 应用。而 Netlify 等也通过Functions支持了框架的SSR，使开发者在JAMStack平台上运行 SSR 成为可能。

ISG 应用案例：适用于内容规模庞大且需定期更新的网站，这类站点希望兼顾静态性能和内容新鲜。典型案例包括：

• 大型电商或分类信息网站：有成千上万商品/列表页。采用 SSG 预生成全部页面构建时间过长、更新一个商品得重建全站不现实；采用 SSR 每次请求又浪费性能且大部分商品数据其实不常变。ISR 提供了折中方案：初始部署时只生成主要页面（例如热门商品、首页、主要分类），长尾商品页在用户第一次访问时自动生成并缓存，以后访问快速，同时设定定期重新验证库存价格。例如某电商用 Next.js ISR，为商品页设置每天再生成一次，这样价格不会老旧超过24小时，热门商品还可以更频繁。这样网站无需庞大后端支持，就能靠CDN服务海量商品页，同时保持一天内的内容新鲜度。
• 内容发布平台/博客集合：比如一个有海量文章的资讯站或博客平台，文章总数持续增加。采用ISR可以避免每发一篇文章都重建整个网站，只生成新的文章页，其它旧文章保持缓存。首页或分类页则设短的 revalidate 时间以包含新文章链接。这种架构非常适合使用 Headless CMS + 静态前端的方案——当编辑发布内容时，通过调用前端的 revalidate API，触发对应页面更新，其余部分不受影响。实践中，Vercel 平台推行的很多案例（如使用 Next.js 的 Notion 静态站点、内容聚合网站等）都成功利用 ISR 来增量更新内容。
• 渐进迁移的大型站点：如果一个既有网站页面众多，想迁移到静态架构但又无法一次性预生成全部页面，那么 ISR 可以帮助逐步迁移。先预生成核心流量页，其余页面保持fallback，当有流量时再生成。这种场景下，初始构建时间大大减少（无需一次构建所有），站点上线更快，然后根据真实访问逐渐填充缓存。例如中文社区常提到的增量迁移理念，在 Next.js 中就有团队使用 ISR 把一个旧站的页面陆续静态化而不用停机。

框架方面，Next.js 是 ISR 的主要推动者，许多上述案例都用 Next.js 实现。值得一提的是，Vue/Nuxt 也开始支持类似ISR的机制：通过社区插件或 Vercel Adapter（如 nuxt-vercel-isr）可以让 Nuxt 3 实现按需静态再生。此外，Gatsby 在新版中引入了 DSG（Deferred Static Generation）和 DPR（Distributed Persistent Rendering）等概念，与ISR思想相近，即有选择地延迟部分页面生成。这些技术都在解决同一问题：让构建时间与内容规模解耦，同时保持静态输出的性能。对于团队而言，ISR 这样的技术可以在不放弃SEO和速度的前提下，引入一定的动态能力，是现代 Jamstack 项目的一个重要里程碑。

综上所述，没有一种渲染策略是万能的，每种都有其适用场景和局限。很多现代框架（Next、Nuxt 等）甚至允许同一个网站中不同页面采用不同策略——比如博客文章用 SSG、用户账户页用 SSR、新闻列表用 ISR。这种灵活性结合平台支持，能够让开发者根据具体需求权衡：以静态优先，辅以服务端渲染和增量更新，既保障了性能和SEO，又提供了必要的动态交互。在选择渲染方案时，团队需要综合考虑内容更新频率、用户体验期望、SEO需求以及部署维护成本，择优或混合使用上述策略，才能构建出既快速又智能的现代 Web 应用。