静态站点生成的取舍

三种模式的本质差别

• SSG：构建时把页面渲染成 HTML 文件，请求时直接返回文件。
• SSR：每次请求都渲染一次。
• ISR / 增量：构建时生成，之后按需或定时重新生成。

三者的区别只有一个变量：HTML 是什么时候生成的。

SSG 的真实优势

快，而且稳定。 返回一个静态文件，TTFB 通常在 20ms 以内，且不受数据库负载影响。源站挂了，CDN 上的缓存还能继续服务。

便宜。 不需要常驻 Node 进程，可以放在对象存储 + CDN 上，成本接近于零。

安全面小。 没有运行时的数据库连接、没有会话、没有注入点。

这三点对内容型站点（博客、文档、产品介绍页）几乎是压倒性优势。

SSG 的真实代价

构建时间随页面数线性增长。 1000 篇文章，每次构建要渲染 1000 个页面，加上图片处理，五分钟起步。改一个错别字也要等五分钟，这个体验会让人开始拖延发布。

动态内容做不了。 评论、点赞、搜索、登录，这些必须走 API。SSG 只是把「壳」静态化，交互部分仍然是客户端请求。

内容更新有延迟。 从「写完」到「线上可见」中间隔着一次构建和部署。对新闻类站点，这个延迟不可接受。

什么时候 SSG 是错的

• 内容一天更新几十次（新闻、社区）；
• 页面需要根据用户身份变化（登录后的首页）；
• 页面数量上万且增长快（构建时间失控）；
• 需要实时数据（库存、价格、评论数）。

反过来，这些情况 SSG 很合适：

• 文档站、博客、落地页；
• 内容更新频率低于每小时一次；
• 页面数量在几百到几千；
• 流量大但内容稳定。

混合才是常态

现代框架基本都支持混合：首页 SSG，文章页 SSG，评论区客户端渲染，后台 SSR。

判断标准不是「整个站点用什么」，而是每个路由用什么：

路由	模式	理由
/ 首页	SSG + 增量	内容变化慢，流量大
/posts/:slug	SSG	文章不变，缓存友好
/archive	SSR 或增量	依赖文章总数，变化频繁
/admin/*	SPA / SSR	需要登录态，不能缓存
/api/*	服务端	动态

ISR 解决的是什么

ISR（增量静态再生成）的核心是：首次请求时生成，之后按策略更新。

它把「构建时全量渲染」改成「访问时按需渲染 + 缓存」。好处是构建快、内容也能较快更新；代价是需要一个能存缓存的运行时（不能纯静态托管）。

对自建服务，这其实就是「服务端渲染 + 页面缓存」。名字不同，机制一样。

一个务实的判断流程

1. 这个页面需要登录态吗？需要 → 不能静态化。
2. 内容一天变几次？超过 10 次 → 不适合纯 SSG。
3. 页面总数多少？超过 5000 → 构建时间要重新评估。
4. 能接受「发布后几分钟才生效」吗？不能 → 用增量或 SSR。

四个问题走完，方案基本就定了。

别忽略图片和字体

SSG 站点最容易忽略的是静态资源的处理。1000 篇文章每篇两张图，构建时如果每张都做一次压缩和响应式变体，时间会翻倍。

实践建议：图片处理放在构建之外（上传时就处理好），构建只负责复制。或者用独立的图片服务，构建时只写 URL。

收尾

SSG 不是「更现代的 SSR」，它是「用构建时间换运行时间」。

内容变化频率低、页面数量可控，这个交易划算；反之，就是在给自己制造等待。

构建时长失控之后

当文章涨到五千篇，你会发现构建时间从三分钟变成四十分钟。这时候有几种做法，代价各不相同。

增量构建：只重建发生变化的页面。多数框架支持，但依赖精确的依赖追踪，一旦追踪有漏，就会出现「改了没更新」这种最难排查的问题。

分片构建：把内容按年份或分类拆成多个子站，各自独立构建。复杂度上升，但每次只需要重建一小块。

放弃全量预渲染：只预渲染首页、归档和热门文章，其余走按需生成。这是最务实的折中——把「静态」留给真正的高频页面。

判断标准是：构建时间是否已经影响到发布频率。如果因为「要等四十分钟」而把三次小改动攒成一次大发布，那构建成本已经变成了质量风险。

静态托管的一个隐藏成本

把产物放到对象存储 + CDN，成本接近于零，但要注意 404 与重定向的处理。

单页应用需要把未匹配的路径回退到 index.html，静态站点需要生成 404 页面，带尾斜杠和不带尾斜杠的 URL 要统一。这些在自建服务器上是一条 Nginx 规则，在对象存储上要单独配置，而且各家行为不一致。

上线前用一批真实 URL 跑一遍：带参数的、带尾斜杠的、大小写不同的、不存在的。这四类各测一条，能提前发现大部分配置问题。

最后一条判断依据

如果你还在犹豫，问一句：这个站点的内容，是「发布」出来的，还是「执行」出来的？

发布出来的（文章、文档、页面），SSG 天然合适；执行出来的（按条件查询、按身份渲染、按时间变化），SSR 更合适。

多数站点两者都有。按路由分开处理，比全站统一某一种模式更省事，也更省资源。