活动页面静态化渲染：SSI、ISR 与边缘渲染分别适合什么场景

大促、发布会、专题活动这类页面有两个共同特征：访问量在某个时间点瞬间冲高，而页面内容在活动期内几乎不变。如果每次请求都让服务端实时查库、拼装模板渲染，高峰期数据库和应用很容易被打满。把这类页面"静态化"是最直接的抗压手段，但静态化也分好几种实现，选错了要么扛不住流量，要么改个文案还要全量重新发布。本文讲清 SSI、纯静态、ISR 增量静态再生成、边缘渲染几种方案的原理、取舍和落地方式。

一、先判断你的页面适不适合静态化

静态化的前提是"内容可预先计算、对不同用户差异小"。先按两个维度给页面分类：

• 内容更新频率：活动期内基本不变 / 分钟级可接受延迟 / 必须实时；
• 用户个性化程度：所有人看到的一样 / 只有少量个性化区块 / 高度千人千面。

适合静态化的是"更新慢、个性化弱"的主体内容；个性化的那一小块（如用户昵称、购物车数量）应当剥离出来，用客户端接口异步拉取，而不是因此让整页走动态渲染。这是静态化最重要的设计原则：静态的归静态，动态的用边缘片段或客户端补。

二、方案一：纯静态发布（SSG）

最彻底的做法是构建期就把页面生成成 HTML 文件，发布到 CDN/对象存储，用户请求直接命中静态文件，源站几乎零压力。

# 构建期为每个活动生成独立 html，再同步到对象存储与 CDN
npm run build:activities
aws s3 sync ./dist/activity s3://activity-bucket/ --delete
aws cloudfront create-invalidation --paths "/activity/*"

优点是性能与抗压最好、可被 CDN 全缓存、安全性高（没有动态执行面）；缺点是任何改动都要重新构建发布，适合内容在活动期高度稳定的页面。

三、方案二：SSI 边缘片段组装

当页面有"公共头尾 + 活动主体 + 少量动态片段"时，可以用 SSI（Server Side Include）在 CDN/网关层把多个片段拼成一页：主体片段长缓存，动态片段短缓存或实时回源。

# 活动主体长缓存，库存/时间等片段单独短缓存
location /activity/ {
  ssi on;
  add_header Cache-Control "public, max-age=300";
}
location ~ ^/ssi/(stock|timer) {
  internal;
  proxy_pass http://fragment_upstream;
  add_header Cache-Control "no-cache";
}

页面里用 SSI 指令引入片段：

<!--#include virtual="/ssi/stock?actId=101" -->

好处是公共部分享受缓存、易变部分独立更新，改库存逻辑不用重发整页；代价是引入了片段组装的复杂度和少量边缘计算开销，需要 CDN 支持 SSI 或等价的边缘包含能力。

四、方案三：ISR 增量静态再生成

ISR（Incremental Static Regeneration）的思路是：页面首次被访问时若已有静态产物就直接返回，同时在后台按设定的"再验证间隔"异步重新生成，下次访问拿到新版本。它兼顾了静态的性能和"内容能自动更新"。

// 伪代码：页面级 ISR，revalidate 表示缓存有效秒数
export async function getStaticProps() {
  const data = await fetchActivity(101);
  return { props: { data }, revalidate: 60 }; // 最多 60 秒陈旧
}

配合"按需再生成"，运营改了内容后调用一次失效接口，对应页面立即在下次访问时重建：

# 内容变更后主动触发该页重新生成
curl -X POST "https://host/api/revalidate?path=/activity/101"

ISR 适合"页面很多、单个更新不频繁、能接受秒级到分钟级延迟"的场景，比如大量商品详情、城市活动页。要注意陈旧窗口内用户可能看到旧内容，对售价、库存这类强一致信息不能只靠 ISR，仍需客户端实时校准。

五、方案四：边缘渲染（Edge SSR）

把渲染逻辑下沉到离用户最近的边缘节点，结合边缘缓存做"首访回源、其后边缘命中"，并能在边缘读取地理位置、AB 分组等做轻量个性化：

// 边缘函数伪代码：先查边缘缓存，未命中再回源渲染并缓存
export default async function (req) {
  const key = "/activity/101:" + req.geo.country;
  const cached = await edgeKV.get(key);
  if (cached) return new Response(cached, { headers: { "cache-status": "HIT" } });
  const html = await renderAtEdge({ actId: 101, region: req.geo.country });
  await edgeKV.set(key, html, { ttl: 60 });
  return new Response(html);
}

它比集中式 SSR 延迟更低、比纯静态更灵活，但调试、冷启动、边缘能力上限都要评估，复杂的业务逻辑仍应留在中心服务，边缘只做"组装与轻计算"。

六、几种方案怎么选

实践中往往是组合：活动主框架走 SSG/ISR 长缓存，库存与倒计时走 SSI 或接口短缓存，用户昵称购物车走客户端异步。

七、踩坑清单

• 为了一小块用户昵称让整页动态渲染，丢掉静态化最大的抗压红利；
• 售价、库存只靠 ISR 缓存，陈旧窗口内出现超卖或错误售价；
• CDN 缓存键没区分地域/端，导致不同版本内容互相串；
• 重新发布后忘记刷新 CDN，用户长期命中旧文件；
• SSI 片段服务故障没有降级，整页跟着报错，需要给片段准备兜底静态值；
• 把复杂业务逻辑塞进边缘函数，冷启动和调试成本反而超过集中式。

八、工程落地建议

落地顺序建议从成本最低的纯静态开始：能预生成的全部预生成并推到 CDN；再按"哪里易变"逐步引入 SSI 片段或 ISR；只有确实需要就近个性化时才上边缘渲染。无论哪种方案，都要准备缓存失效预案（发布即刷新、内容变更主动 revalidate）、片段故障兜底，以及压测时专门验证"缓存未命中风暴"——大量缓存同时过期、请求全部回源，是活动页最容易崩的时刻，可以通过给 TTL 加随机抖动、预热热门页来缓解。上线前用真实流量模型分别压"全命中"和"全回源"两种极端，才能确定系统的真实下限。

九、上线前复盘清单

1. 页面是否做了静态/动态拆分，个性化是否剥离为异步接口；
2. 主页面是否被 CDN 长缓存，缓存键是否区分必要维度；
3. 售价库存等强一致信息是否有实时校准、不依赖陈旧缓存；
4. 内容更新后是否有可靠的失效与再生成路径；
5. 片段或边缘函数故障时是否有兜底、不拖垮整页；
6. 是否压测过缓存同时失效的回源风暴并做了 TTL 抖动与预热。

结语

静态化不是"把页面做成死的 HTML"这么简单，它的本质是把"可预测的计算"尽量前移、把"易变和个性化"控制在最小范围。理解 SSG、SSI、ISR、边缘渲染各自更新与缓存的边界，再按页面的更新频率和个性化程度组合使用，活动页就能在流量洪峰里既稳得住、又改得动。