先把问题说清楚
个人内容站的典型负载是：每天几十到几千次访问，内容更新频率按天算。这个负载特征决定了——绝大多数纯静态方案都够用，而且更省钱。
但纯静态有两个场景会卡住：
- 内容更新后要重新构建。如果一篇文章改个错别字都要等一次 CI，写作体验会很差。
- 需要按请求做判断。比如「作者登录后能看到草稿预览」，这在纯静态里做不到。
三种方案的实际体验
| 方案 | 首字节 | 发布延迟 | 运维成本 | 适合场景 |
|---|---|---|---|---|
| 纯静态（SSG） | 最快 | 需重新构建 | 几乎为零 | 内容极少变 |
| 边缘 SSR | 快 | 即时 | 低 | 需要登录态 / 频繁更新 |
| 传统 SSR（Node 服务器） | 中等 | 即时 | 高（要保活） | 复杂服务端逻辑 |
我最后的选择：边缘 SSR + 强缓存
理由不是「SSR 更先进」，而是它在两个约束之间取了最省事的平衡点：
- 内容改完立刻生效，不用等构建 → 写作体验好
- 跑在边缘节点，没有「服务器挂了」这回事 → 运维成本接近静态
- 再加一层 Cache API，命中缓存时几乎等于静态
关键在最后一条。把缓存做对之后，SSR 的运行时开销被摊薄到可以忽略：
// 读缓存 → 命中直接返回（不走模板渲染）
const cached = await caches.default.match(request);
if (cached) return cached;
// 未命中 → 渲染 → 写入缓存（带版本号，避免脏读）
const res = await renderPage();
ctx.waitUntil(caches.default.put(request, res.clone()));
return res;什么情况下我会劝你别上 SSR
如果你满足以下全部条件，纯静态更划算：
- 内容一个月才改一次
- 没有登录/草稿预览需求
- 不想碰任何服务端代码
别为了「架构好看」给自己加一层运行时。 个人项目最大的成本是你的注意力，不是服务器。
反过来的坑
如果你确实需要 SSR，有两个坑要提前避开：
- 别在渲染路径里做串行请求。三个 API 串行等待 = 三倍 TTFB，全部改成
Promise.all。 - 别指望 SSR 解决 SEO。SEO 取决于内容质量和结构，SSR 只是让爬虫能读到内容——这是必要条件，不是充分条件。
