SSG静态生成与ISR增量再生成

CH-03-07-019·约 20 分钟·编程语言与开发工具·更新 2026-08-10

想象你经营一家蛋糕店，明天要接待一百位客人。笨办法是提前把所有蛋糕都烤好放进展示柜，客人来了直接拿走，零等待——这就是静态站点生成（SSG）。可难题来了：如果某款蛋糕的配方中午变了，难道要把整柜蛋糕全部回炉重造吗？聪明的店员会给每个蛋糕贴上“保质期”标签，过期的那款单独重烤，其余蛋糕继续售卖——这就是增量再生成（ISR）。本篇文章就用这家蛋糕店的故事，把 SSG 与 ISR 的原理、配置、选型一次讲透。

岗位关联

掌握 SSG 与 ISR，你就能同时拥有“首屏秒开”和“内容常新”两种能力。这是内容型网站性能优化的核心技能，也是前端工程师走向全栈工程化的重要跳板。

可视化演示
SSG核心原理
ISR核心原理
构建流程对比
Next.js配置
适用场景
性能与成本
选型决策
混合渲染策略
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示SSG构建时静态生成全量页面流程、ISR增量再生成Stale-While-Revalidate机制及SSG/ISR/SSR/CSR四种渲染策略对比，切换模式理解现代前端渲染方案。

本节配有交互动效（进入视口后自动加载，约 3KB）。

SSG构建时静态生成构建时获取数据并预渲染所有页面为静态HTML，部署到CDN获得极致首屏性能 getStaticProps在build阶段执行，生成JSON数据文件和HTML，无需服务器运行时 Build: fetch data → render HTML → deploy CDN | TTFB ≈ 0 SSG适合内容稳定、更新频率低的博客文档等内容型网站

SSG核心原理

蛋糕店的第一课：什么甜点最省心？答案是那些可以提前做好的招牌款。烘焙师在前一天晚上把曲奇、慕斯、拿破仑全部烤好塑形，放进展示柜。第二天顾客推门进来，报出名字就直接从柜里取货，从下单到交付只要几秒钟。这就是 SSG 的哲学——把运算量提前消化在营业之前，用“预生成”换“秒回”。

在网站世界里，SSG 就是在构建阶段执行数据获取和页面渲染。Next.js、Astro、Gatsby 这类框架在 npm run build 时，会读取你的数据源（数据库、CMS、Markdown 文件），调用每个页面的组件代码，产出纯静态的 HTML、CSS 和 JS 文件。这些文件不依赖 Node.js 服务进程，任何静态服务器都能托管。用户请求到达时，服务器只是把文件原样返回，就像蛋糕展示柜里的现成甜点。

把静态文件部署到 CDN 后，全球各地的用户都会从最近的边缘节点拿到页面，网络延迟被压缩到极致。而且因为没有运行时逻辑，攻击面变小、宕机风险降低、部署流程简化为“传文件”。这就是 SSG 的四个支柱：构建期执行、静态文件产出、CDN 加速、部署简单。

回到蛋糕店：SSG 就像提前把全店蛋糕都做好，营业期间不再开烤箱。代价是准备日很辛苦，但营业日轻松、顾客满意。如果你要卖 10 款甜点，烘焙时间就是 10 款制作时间之和——这个成本在决策时必须想清楚。

T_{\text{build}} = \sum_{i=1}^{N} t_i

构建总时长等于每一页生成耗时的总和。页面越多、单页数据越重，构建时间就越长——这就是全量构建的成本公式。

T_build（构建总时长）从执行构建命令到所有静态文件就绪的总时间，它是每一页耗时累加的结果。
$T_{\text{build}}$
Σ 累加符号把 N 个页面各自的生成时间逐个相加，表示“全量生成”而非部分生成。
$\sum_{i=1}^{N}$
t_i（单页生成耗时）每个页面从拉取数据到渲染成 HTML 所花费的时间，它由数据大小和模板复杂度决定。
$t_i$

ISR核心原理

蛋糕店的新难题：一星期前烤好的草莓鲜奶油蛋糕，保质期只有两天。如果每天都有顾客点它，你却只能端出三天前的老蛋糕，口碑迟早崩盘。店员想出一个主意：每个蛋糕盒上贴一张“保质期”标签，时间到了就检查这一个款式，只重烤那一个，其他甜点完全不动。

这就是 ISR 的核心机制。它依然采用 SSG 的预生成思路，但给每个页面附加了一个 revalidate 时间窗口。窗口内，CDN 直接返回缓存文件，零计算开销；窗口过期后，第一次请求会先拿到旧版本页面，同时后台触发一个重新验证任务：重新请求数据、重新生成 HTML、替换 CDN 缓存。下一个用户再访问时，拿到的就是新蛋糕了。

这个机制有三个关键点：一是“先旧后新”——过期后的首次访问先返回旧内容，避免用户干等；二是“后台异步”——重新生成在后台完成，不阻塞请求；三是“按需增量”——只有过期页面被重建，其他页面维持缓存不动。这种设计让 ISR 既能享受 CDN 的极速，又能定期吸收源头更新。

回到蛋糕店：保质期标签就是 revalidate 数字，巡检员就是后台重新验证任务。ISR 的精髓不是“立刻变新”，而是“不打扰顾客地悄悄换新蛋糕”——牺牲一点点实时性，换来极大的性能收益。

T_{\text{serve}} =\begin{cases}T_{\text{static}}, & t_{\text{now}} < t_{\text{gen}} + R \\T_{\text{stale}} + T_{\text{regen}}, & t_{\text{now}} \geq t_{\text{gen}} + R\end{cases}

用户拿页面的耗时分两种情况：保质期内直接读静态缓存；过期后先返回旧版本，再在后台完成重建。

T_serve（用户响应耗时）用户请求一个页面到拿到 HTML 的总时长，它是判断体验好坏的核心指标。
$T_{\text{serve}}$
保质期内分支当前时间 t_now 小于生成时间 t_gen 加 revalidate 值 R 时，直接返回静态缓存，耗时几乎只有网络延迟。
$t_{\text{now}} < t_{\text{gen}} + R$
过期分支当前时间超过了 R 窗口，系统先返回旧静态文件 T_stale，同时在后台执行重建任务 T_regen。
$T_{\text{stale}} + T_{\text{regen}}$

构建流程对比

蛋糕店老板算了笔账：如果小明把店里上百款蛋糕全部重烤一遍，得花一整个晚上；但如果只为卖完的那款补货，十分钟就够了。全量更新和增量更新的成本差距，在页面数量变大后会急剧放大。

SSG 的更新方式是“全量重建”。你改了数据库里一条商品描述，就需要重新执行构建命令，把所有页面重新生成一遍再部署。这属于全量构建。ISR 的更新方式是“增量路径”：每个页面独立设置 revalidate，过期页面单独重建。更新一篇文章只需要生成那一个页面，其他页面继续对外服务。

从用户体验看，两者首屏加载都很快，因为静态文件都由 CDN 返回；差别主要体现在更新时机和 TTFB 上。SSG 更新后首次请求可能还没部署，用户仍看到旧版本；ISR 过期后的首次请求虽然也返回旧内容，但后台重建一旦完成，后续请求立刻命中新内容。TTFB 方面，SSG 和 ISR 命中的都是 CDN 缓存，同样远快于 SSR 的动态渲染。

全量构建像重装整个店面：虽然彻底，但每次都要兴师动众。增量重建像只给缺货的货架补货：快、准、省。理解这个成本差异，是后续选型的核心依据。

T_{\text{full}} = \sum_{j=1}^{M} t_j \approx M \times \bar{t}, \qquad T_{\text{inc}} = t_k \ll T_{\text{full}}

全量构建耗时约等于页面总数乘以平均单页耗时；增量重建只需一个页面的时间，两者差距巨大。

T_full（全量构建总耗时）SSG 每次部署都要把 M 个页面全部重新生成一遍，是所有页面耗时之和。
$T_{\text{full}} = \sum_{j=1}^{M} t_j$
平均近似若每页耗时相似，总时长可近似为页面数 M 乘以平均单页耗时 t̄。
$M \times \bar{t}$
T_inc（增量重建耗时）ISR 只重建变化的第 k 个页面，耗时为 t_k。
$T_{\text{inc}} = t_k$
远小于符号（≪）单页耗时远小于全量耗时，所以增量更新的成本几乎可以忽略。
$T_{\text{inc}} \ll T_{\text{full}}$

Next.js配置

蛋糕店的保质期标签怎么贴？需要一套标准作业流程。在 Next.js 的世界里，这套流程主要由三个配置项完成：revalidate、generateStaticParams 和 fallback。

最常使用的是 revalidate 字段。在页面文件中导出它，就能开启 ISR：

这段代码告诉 Next.js：这个页面以静态方式生成，但每 60 秒检查一次是否需要重建。revalidate 的值就是“保质期”的秒数。对于动态路由（比如博客的 /posts/[id]），还需要用 generateStaticParams 预先声明要生成哪些路径参数，框架才会为这些路径构建静态页面。而 fallback 选项则决定未预生成的路径怎么处理：false 直接 404，true 先返回降级内容再后台生成，'blocking' 则等待服务端渲染完成后返回。

这些配置可以精确到路径级别。首页用 revalidate = 3600，详情页用 revalidate = 30，静态页面干脆不写 revalidate——每个蛋糕贴不同的保质期标签。

配置 ISR 很像给蛋糕定保质期：草莓蛋糕保质期 2 天，你就设 1 天；拿破仑保质期 5 天，你就设 2 天。关键在于估算内容真实的新鲜度，而不是拍脑袋。

R = \left\lfloor \frac{T_{\text{life}}}{k} \right\rfloor, \quad k \in \{2, 3, 4, 5\}

revalidate 值约等于内容保鲜期除以一个安全系数。宁可多刷几次，也别让用户看到过期数据。

R（revalidate 秒数）你写入配置的数值，代表页面缓存的最长有效时间，单位是秒。
$R$
T_life（内容保鲜期）数据平均多久变化一次。比如商品价格每小时变，T_life 就是 3600 秒。
$T_{\text{life}}$
k（安全系数）把保鲜期除以 2 到 5，提前刷新，避免内容实际已变但缓存还“假装新鲜”。
$\left\lfloor \frac{T_{\text{life}}}{k} \right\rfloor$

js5 行

export default function BlogPost({ post }) {  return <article>{post.content}</article>;} export const revalidate = 60; // 60 秒后重新验证

适用场景

蛋糕店开始分类经营：有的甜点一周才卖一次，有的甜点每天配方都在变。聪明的老板会给不同品类安排不同的生产策略，网站页面同样如此。

最适合 SSG 的是内容高度稳定的页面。博客文章发布后极少修改，文档站点的 API 说明一个月才更新一次，企业官网的首页介绍可能半年不变。这些页面用 SSG 一次性生成，之后长期命中 CDN 缓存，性能成本双优。同时，静态 HTML 对搜索引擎爬虫极度友好，SEO 表现优异。

最适合 ISR 的是“内容会变但变化频率不高”的场景。电商商品页的价格和库存每天变动几次；新闻网站的排行榜每小时刷新；文档站随版本发布定期更新。ISR 让这类页面在“静态收益”和“动态新鲜”之间取得平衡。而内容每秒都在变的场景——股市行情、实时弹幕、在线聊天——就不适合 ISR，应选择 SSR 或客户端实时渲染。

蛋糕店的启示：卖得慢的招牌款提前做好最省心，卖得快的爆款要频繁补货，而刚出炉就要吃的舒芙蕾只能在顾客点单后现做。选型不是“哪个技术厉害”，而是“我的内容像哪类蛋糕”。

\text{方案} =\begin{cases}\text{SSG}, & f_{\text{update}} = 0 \\\text{ISR}, & 0 < f_{\text{update}} < f_{\text{cap}} \\\text{SSR}, & f_{\text{update}} \geq f_{\text{cap}}\end{cases}

决策准则：内容从不更新就用 SSG；低频更新用 ISR；高频更新才考虑 SSR。

f_update（内容更新频率）同一页面内容在单位时间内变化的次数，它是选型的第一判据。
$f_{\text{update}}$
SSG 分支更新频率等于 0，内容恒定，一次性构建最划算。
$\text{SSG}, \quad f_{\text{update}} = 0$
ISR 分支更新频率大于 0 但低于阈值，用 ISR 定时增量重建。
$\text{ISR}, \quad 0 < f_{\text{update}} < f_{\text{cap}}$
SSR 分支更新频率超过阈值，缓存难以命中，只能走服务端动态渲染。
$\text{SSR}, \quad f_{\text{update}} \geq f_{\text{cap}}$

性能与成本

顾客评价一家蛋糕店，核心就俩字：快和鲜。网站性能指标千千万，但普通用户感知最强的就是 TTFB——从发起请求到浏览器收到第一个字节的时间。这个指标直接决定了页面首屏的“空白等待期”。

SSG 和 ISR 的 TTFB 几乎都来自网络传输。由于页面是预生成的静态文件，部署在 CDN 上，用户请求到达最近的边缘节点后，服务器直接返回文件内容，不需要执行模板渲染、不需要查询数据库、不需要等待后端接口。相比之下，SSR 页面每次请求都要在服务器上经历“查数据 + 渲染 HTML”的完整流程，TTFB 自然高出几个数量级。

成本方面，SSG/ISR 把渲染压力转移到了构建期。CDN 缓存命中了绝大多数请求，源站服务器压力极小，甚至可以缩容到几乎没有。但要注意构建时长的成本：十万个页面的站点每次全量构建可能需要数十分钟，而 ISR 把这种压力分摊到运行时的增量重建中，单个页面重建只需几百毫秒。性能与成本的天平，就这样被 ISR 悄悄拨动。

这就像蛋糕店把烘焙变成“装盘”：蛋糕提前烤好，顾客来了只需要端出来。ISR 的增量重建则进一步把“偶尔补烤”的成本也压低了。对用户和运维来说，这是双赢的结构。

\text{TTFB} = t_{\text{net}} + t_{\text{render}} + t_{\text{db}} \approx t_{\text{net}}

静态方案的 TTFB 等于网络传输时间；渲染时间和数据库查询时间约等于零。

TTFB（首字节时间）用户请求发出到响应首个字节到达浏览器的时长，包含网络传输、渲染、数据库三部分。
$\text{TTFB} = t_{\text{net}} + t_{\text{render}} + t_{\text{db}}$
t_render（渲染耗时）服务端执行组件渲染、生成 HTML 的时间，SSG/ISR 在构建时已完成，运行期约等于 0。
$t_{\text{render}} \approx 0$
t_db（数据库耗时）查询接口获取数据的时间，静态页面不查询数据库，同样约等于 0。
$t_{\text{db}} \approx 0$
结果近似三大成本削去两个，只剩网络传输 t_net，所以 TTFB 被压到极致。
$\text{TTFB} \approx t_{\text{net}}$

选型决策

蛋糕店老板筹备分店时，不会只问“哪种蛋糕好吃”，而是会看客流量、食材保质期、厨师团队水平。选择渲染方案也类似，需要从四个维度综合打分。

首先是内容变更频率。内容完全不变，直接 SSG；变化慢，选 ISR；变化极快，只能 SSR。其次是实时性要求。如果用户必须看到秒级最新数据（比如库存余量），ISR 的“先旧后新”策略就不够用。第三是团队维护成本。SSG 部署最简单，任何静态服务器都能托管；ISR 需要有后台重新验证能力的平台（如 Vercel、Netlify）配合；SSR 则需要维护 Node.js 服务、监控 CPU 和内存。第四是渐进迁移路径：已有的 SSR 项目可以逐步把低频页面改成 ISR，不需要一次推倒重来。

把这四个维度量化为一个评分模型：给“更新频率需求”、“性能需求”、“构建成本”分配不同权重，加权求和后得分最高的方案胜出。

蛋糕店的经验是：没有最好的蛋糕，只有最合适的菜单。选型决策要拿着数据说话——统计内容更新频率、测量性能需求、盘点团队运维能力，再用量化模型做选择，而不是凭直觉跟风。

S = w_1 \times U_{\text{freq}} + w_2 \times P_{\text{perf}} - w_3 \times C_{\text{build}}

方案得分 = 更新需求权重 + 性能需求权重 - 构建成本权重。得分高者优先选用。

S（综合得分）对候选方案的总评分，用于量化比较 SSG、ISR、SSR。
$S$
w1 × U_freq（更新权重）内容更新需求越高，该值越大，向 ISR/SSR 倾斜。
$w_1 \times U_{\text{freq}}$
w2 × P_perf（性能权重）首屏体验要求越高，静态方案的优势越大。
$w_2 \times P_{\text{perf}}$
减号后置成本构建时长和运维成本作为负分项，页面越多这项惩罚越明显。
$- w_3 \times C_{\text{build}}$

混合渲染策略

成熟的大蛋糕店不会只卖一种产品策略：经典款提前烤好，时令款每天补货，现烤舒芙蕾等客再制。现代网站也在朝这个方向演进——一个站点内混用 SSG、ISR 和 SSR。

混合渲染的具体做法是：把整个应用按页面拆开，分别采用最合适的策略。老博客文章用 SSG，永久缓存；热点频道用 ISR，10 分钟增量更新；实时活动会场用 SSR，每次请求动态渲染。Next.js 从 13 版本开始全面支持这种“每页独立渲染策略”，这正是它成为全栈框架核心竞争力的原因。

ISR 与 CDN 的融合让这套策略如虎添翼：ISR 页面仍然以静态文件形态存放在 CDN 边缘，只是后台多了一条“重新验证”通道。更进一步，边缘函数（Edge Functions）可以在离用户最近的节点执行轻量逻辑，让部分动态判断（如 A/B 测试、用户分流）也在边缘完成，而核心页面内容依旧静态托管。未来静态、动态的边界会越来越模糊，但“能静态就静态，动态放在边缘”是大方向。

蛋糕店的终极形态是“组合拳”：展示柜里摆着提前烤好的经典款，冷藏柜里放着定时补货的时令款，现做窗口忙着顾客点单的定制款。多一点架构弹性，就多一分对变化世界的从容。

A_{\text{global}} = 1 - (1 - a_{\text{CDN}})(1 - a_{\text{origin}})

混合架构的整体可用率 = 1 -（CDN 不可用概率 × 源站不可用概率）。两层互为备份，可靠性成倍提升。

A_global（整体可用率）用户能正常拿到页面的概率，混合架构的目标就是把它逼近 100%。
$A_{\text{global}}$
(1 - a_CDN)（CDN 失效概率）CDN 边缘节点出故障的可能性，由于节点遍布全球，单点故障很难影响全局。
$(1 - a_{\text{CDN}})$
(1 - a_origin)（源站失效概率）源服务器宕机的可能性，同样不等于 0。
$(1 - a_{\text{origin}})$
可靠性叠加两者同时失效用户才真正受影响，所以整体不可用率是两个小概率的乘积，可用率因此极大提升。
$1 - (1 - a_{\text{CDN}})(1 - a_{\text{origin}})$

AI 应用场景

博客与内容站的自动渲染优化

阶段：构建时优化与运行时增量更新

解决的问题：内容型网站文章多、更新频繁，若全部用 SSR，每次请求都实时渲染，服务器压力大且 TTFB 高；若全部用 SSG，每次改稿都要全量部署。ISR 让每篇文章独立设置保质期，改一篇文章只重建那一页。

具体案例：一个日更 10 篇的公众号官网，历史文章用 SSG 永久缓存，当日热点文章用 ISR 每 5 分钟验证一次。用户访问旧文章秒开，新文章延迟最多 5 分钟。编辑发布新文章后，框架自动增量生成该页面，无需手动触发全站部署。

电商商品页的首屏提速

阶段：部署与缓存策略优化

解决的问题：电商商品详情页包含大段介绍、评价、参数表格，若用 SSR 则在高峰期拖垮服务器。SSG 预生成商品页 + ISR 定时刷新价格和库存，可在保持 CDN 缓存的同时维持信息新鲜。

具体案例：某商城有 5 万件商品，每次全量构建耗时 40 分钟。引入 ISR 后，热卖商品 revalidate 设为 30 秒，普通商品设为 10 分钟，冷门商品设为 24 小时。价格变动后，只有对应页面在后台快速重建，全站构建频率大幅下降。

文档站的多版本发布

阶段：持续集成与部署

解决的问题：技术文档站随代码版本迭代更新，旧版本文档需要长期保留且内容不变，最新版文档更新较频繁。SSG 处理旧版本文档，ISR 处理最新版本，既保证历史版本稳定访问，又让新版文档快速生效。

具体案例：一个开源项目的文档站，v1.0 和 v2.0 目录用 SSG 静态生成，latest 目录用 revalidate: 60 的 ISR。每次发布新功能，CI 流程只需更新 latest 下的几个页面，整个站点的构建时间缩短 80%。

Python 演示

python37 行

import time PAGES = [f"post-{i}" for i in range(1, 101)]  def render(page):    """模拟渲染单个页面，耗时 2ms"""    time.sleep(0.002)    return f"<article>{page}</article>"  def ssg_build(pages):    """SSG：构建时全量生成所有页面"""    t0 = time.perf_counter()    site = {p: render(p) for p in pages}    return site, time.perf_counter() - t0  def isr_update(cache, page):    """ISR：运行时增量重建单个页面"""    t0 = time.perf_counter()    cache[page] = render(page)    return time.perf_counter() - t0  def main():    site, full_t = ssg_build(PAGES)    print(f"SSG 全量构建 100 页耗时: {full_t:.4f}s")     changed = "post-42"    inc_t = isr_update(site, changed)    print(f"ISR 增量重建单页耗时: {inc_t:.4f}s")    print(f"加速比: {full_t / inc_t:.1f}x")  if __name__ == "__main__":    main()

目的：用一个小型模拟器展示 SSG 全量构建与 ISR 增量重建的成本差异，直观感受两种策略在生产速度上的指数级差距。

site = {p: render(p) for p in pages}模拟 SSG 构建阶段：遍历所有页面，每个页面都执行一遍数据获取与渲染。
t0 = time.perf_counter()在关键操作前后打点计时，用高精度时钟量化构建耗时。
cache[page] = render(page)模拟 ISR 的核心：只重新生成传入的这一页，替换缓存，不动其他页面。
full_t / inc_t算出加速比：100 个页面时 ISR 的速度优势约为 100 倍，页面越多差距越悬殊。

常见误区

误区我设置了 `revalidate: 60`，那用户每次刷新都应该看到最新内容，否则就是缓存没生效。

正解ISR 的机制是“先旧后新”。过期后的第一个用户依然会拿到旧版本页面，同时后台开始重建新页面；只有当重建完成且缓存被替换后，后续用户才会看到新内容。这就像蛋糕保质期到了，店员先取出旧蛋糕热一热垫着，同时去后台烤新蛋糕——第一位顾客可能拿到旧款，下一位顾客才是新款。

为何常见：大家容易把“异步后台重新验证”误解为“同步实时刷新”，忽略了 ISR 设计里刻意保留的“陈旧窗口”。

误区网站用了 SSG，改个错别字都要重新构建部署，太死了，不适合真实项目。

正解SSG 只是“预生成”，不代表不能更新。重新执行构建命令，生成新的静态文件并部署到 CDN，页面就会替换。整个过程可以用 CI/CD 自动化完成，发布的新内容在部署完成后立即生效。缺点是每次都要全量重建，所以才有 ISR 来弥补这个弱点。

为何常见：把“构建时生成”误当成“不可变快照”，忽略了构建流程本身就是可重复触发的。

误区既然 ISR 能增量更新，那把 `revalidate` 设成 1 秒甚至 0，这样每次访问都几乎是最新内容，体验最好。

正解revalidate 过小等于每时每刻都在后台触发重建，ISR 的缓存优势被完全浪费。极端情况下，revalidate: 0 会让页面退化为每次请求动态渲染，相当于放弃 ISR 用了 SSR。合理的做法是估算内容保鲜期，除以安全系数得到配置值，而不是追求数值上的越小越好。

为何常见：把“更新频率”等同于“刷新力度”，忽视了重建同样消耗计算资源，且频繁重建会增加源站负载。

误区ISR 这么好用，那博客、电商、新闻站全部上 ISR 就万事大吉了。

正解内容量庞大且完全稳定的站点（如十万篇历史归档文章）用 SSG 更省心；内容秒级变动的站点（如实时比分）ISR 也扛不住。ISR 的最佳区间是“低频到中频更新”，过高频率会触发大量重建任务，过低频率又没必要引入额外机制。

为何常见：初学者看到一个强大的工具容易产生“万能工具”错觉，忽略了选型要基于业务特征的事实。

误区用了 ISR 就不再需要构建命令了，页面会在运行时自动生成。

正解ISR 依然保留构建阶段。generateStaticParams 预声明的页面在构建时生成，未预声明的路径才依赖 fallback 按需渲染。而且首次访问未预生成的页面时，用户仍然会经历较长的等待。合理使用 ISR 需要同时配置构建期生成和运行期验证，两个阶段缺一不可。

为何常见：被“按需补货”的比喻误导，以为完全不需要提前准备，忽略了 ISR 依然以静态预生成为基础。

面试题

Q1. SSG（静态站点生成）的核心特征是什么？

单选题 · easy

A.每次请求在服务端动态渲染
B.构建阶段提前产出 HTML 文件← 正确答案
C.页面完全依赖客户端 JavaScript
D.仅在用户访问时才生成页面

答案：B。SSG 的核心是在构建阶段把页面提前渲染成静态 HTML 文件，用户请求时直接返回文件。选项 A 是 SSR 的特征，C 是客户端渲染，D 是按需生成，都不是 SSG。

Q2. ISR 中，revalidate 窗口过期后第一次访问，用户会看到什么？

单选题 · mid

A.立即返回 404 错误页面
B.上一次生成的旧版本页面← 正确答案
C.正在渲染中的加载动画
D.自动跳转到源站实时渲染

答案：B。ISR 采用“先旧后新”策略：过期后的首个请求先拿到旧版本，同时后台触发重新验证，重建完成后再替换缓存。用户不会看到 404、加载动画或跳转，只会短暂看到旧内容——就像保质期过后先拿到热好的旧蛋糕。

Q3. 下列哪些场景适合使用 ISR？

多选题 · mid

A.博客内容每日更新← 正确答案
B.电商价格分钟级变化← 正确答案
C.完全不变的静态页面
D.文档站版本不定期发布← 正确答案

答案：ABD。ISR 适合内容低频到中频更新的场景。A 每日更新的博客、B 分钟级变化的价格、D 不定期发布的文档都是不错的选择。C 完全不变的页面用 SSG 更简单高效，无需引入 ISR。

Q4. SSG 与 SSR 相比，主要优势是？

单选题 · mid

A.可以展示用户个性化数据
B.首字节响应时间更短← 正确答案
C.支持实时聊天消息推送
D.不需要任何构建流程

答案：B。SSG 预生成的静态文件直接由 CDN 返回，TTFB 大幅低于 SSR 的实时渲染。个性化数据、实时消息恰恰是静态方案的短板，而且 SSG 必须经历构建流程，D 错误。

Q5. 影响 SSG 全量构建时长的因素包括？

多选题 · mid

A.网站页面总数← 正确答案
B.单页面的数据量大小← 正确答案
C.构建服务器的并发能力← 正确答案
D.用户浏览器的缓存空间

答案：ABC。构建总时长约等于所有页面生成耗时之和，页面越多、单页数据越多、构建机器越慢，耗时越长。用户浏览器缓存与构建过程无关。

Q6. ISR 在 revalidate 窗口内再次请求该页面时会发生什么？

单选题 · mid

A.每次重新执行页面渲染
B.直接命中 CDN 静态缓存← 正确答案
C.强制触发了全站重新构建
D.向数据库查询最新数据后返回

答案：B。revalidate 窗口内页面被视为“新鲜”，CDN 直接返回缓存文件，零渲染零查询。窗口到期后才会走后台重新验证流程，全站重建是 SSG 的行为。

Q7. Next.js 中 generateStaticParams 的主要作用是？

单选题 · mid

A.控制客户端路由之间的跳转
B.为动态路由预生成路径参数← 正确答案
C.修改网页的全局 CSS 样式
D.监听数据库表的实时变化

答案：B。对于 /posts/[id] 这类动态路由，generateStaticParams 返回一个参数数组，框架据此在构建时为每条路径预生成静态页面。它不处理路由跳转、样式，也不监听数据库。

Q8. 选择 SSG、ISR、SSR 时应综合哪些因素？

多选题 · hard

A.内容变更频率← 正确答案
B.实时性要求程度← 正确答案
C.构建与运维成本← 正确答案
D.页面设计的视觉美观度

答案：ABC。选型的核心依据是更新频率、实时性要求和成本承受能力。页面美观度虽然重要，但与渲染方案选择没有直接关系，任何方案都能实现精美设计。

Q9. 既想享受 SSG 的高速缓存，又能定期自动更新内容，应该选择？

单选题 · easy

A.纯客户端渲染方案
B.ISR 增量再生成策略← 正确答案
C.服务端手动写入静态文件
D.浏览器强制清除缓存刷新

答案：B。ISR 正是为“静态优势 + 定期更新”而生的方案：预生成页面、定时验证、按需重建。C 是手工操作，A 和 D 与更新机制无关。

Q10. 关于 ISR 相比 SSR 的优势，下列描述正确的是？

多选题 · hard

A.TTFB 更短且缓存命中率高← 正确答案
B.对源服务器的压力更小← 正确答案
C.用户数据完全实时同步
D.CDN 边缘节点也能正常加速← 正确答案

答案：ABD。ISR 页面以静态文件存在于 CDN，TTFB 短、命中率高，源站压力小，且天然享受边缘加速。但 ISR 不具备实时同步能力，过期后会有“先旧后新”的短暂延迟，C 错误。