Next.js SSR、SSG 与 ISR 对比：何时使用各渲染模式

决策规则 SSR 会在每次请求时生成 HTML，因此非常适合仪表盘、账户页面、结账流程、库存检查，以及任何由 Cookie、权限或用户状态决定展示内容的页面。SSG 会在构建时生成 HTML。它适用于稳定的公开页面，例如文档、帮助文章、落地页和长期有效的教程。ISR 在提供静态交付速度的同时，允许页面按设定间隔刷新。它很适合博客、产品页面、公开排名和对比指南。最快的选择方法是判断 HTML 是否可缓存。如果许多访问者都可以安全地接收同一份 HTML，请使用 SSG 或 ISR。如果响应取决于当前用户或请求，请使用 SSR，或在客户端获取私有部分。实用内部参考：Next.js metadata、PageSpeed checker、meta tag checker、reading time calculator、image format guide。

实用选择表 | 场景 | 优先选择 | 原因 |

运行检查清单 在选择渲染模式之前，请确认 HTML 是否可以缓存、源数据多久变化一次、构建时间是否会随内容量增长，以及 SEO 元数据是否包含在首个响应中。同时也要检查图片、字体和第三方脚本，因为即使渲染策略本身合理，它们也可能拖慢性能。

常见问题

SSR 对 SEO 总是更好吗？

不是。SSG 和 ISR 也可以发送完整的 HTML，而且对于公开内容，它们通常更快。

最安全的默认选择是什么？

稳定页面使用 SSG，偶尔变化的公开页面使用 ISR，请求相关页面使用 SSR。

补充实践说明 当每个请求都可能生成不同的 HTML 时，SSR 最合适，例如仪表盘、账户页面、结账状态、库存检查，以及由 Cookie 或权限塑造的页面。当公开内容足够稳定、可以提前构建时，SSG 很适合使用，包括文档、帮助文章、落地页和长期有效的教程。ISR 介于两者之间：它保持静态交付的速度，同时在选定间隔后刷新页面，适用于博客、产品页面、公开排名和对比指南。一个简单的可缓存性测试通常就能指明方向。如果同一份 HTML 可以安全地服务许多访问者，请选择 SSG 或 ISR。如果不行，请使用 SSR，或将私有部分移到客户端获取。为每条路由记录决策，跟踪缓存命中率，并在内容量、更新频率或个性化发生变化时重新审视选择。渲染策略应逐页决定，而不是为整个项目一次性决定。

实际使用时的检查重点

这篇内容不应该只当作简单摘要来读，更适合用来和自己的情况逐项对照。先确认当前目标、时间限制和可用资源，再按照正文里的判断标准逐步检查。

如果内容涉及运势、比较、计算或工具结果，不要只看最后结论，也要看判断过程。把关键条件记录下来，隔一段时间再复核一次，通常能减少冲动决定。

快速检查清单

• 是否把正文标准换成了自己的实际条件
• 是否区分了必须马上做和可以等待的事项
• 是否通过相关工具或内部链接补充确认
• 涉及日期、金额或规则时是否重新核对最新 기준