SSR、SSG 还是 ISR：如何选择

不存在放之四海皆准的最快架构

无论 HTML 最初是如何生成的，靠近访客的缓存响应都可能很快。一个查询高效的服务端渲染页面，可能比一个发送过多 JavaScript 的静态页面更快。TTFB、内容时效性和响应速度是不同的属性。

这份比较是一个决策框架，而不是对客户系统的基准测试。框架版本、运行时、托管适配器、缓存配置、地理位置和数据访问方式，都会影响结果。

渲染方式及其运维上的取舍
方式	HTML 何时生成	适合的起步用途	需要仔细检查的地方
SSR	请求时生成，视缓存情况而定	需要身份验证或因请求而异的页面	源站工作量、超时和私有缓存的边界
SSG	访问之前，通常在构建时生成	稳定的内容页面和文档	构建时长和发布延迟
ISR	复用已生成的输出并进行刷新	可接受一定过期程度的公开内容	缓存失效、重新生成失败以及首次无缓存访问

账户页面和依赖权限的视图，通常需要在请求时做出判断。把身份验证和授权放在服务器端，并防止私有响应进入共享缓存。流式传输、数据缓存和精心设计的查询可以减少等待，但并不能免去测量的必要。

SSR 并不意味着特定的基础设施成本或必需的集群规模。这些需求取决于负载、每个响应的工作量以及扩展策略。

预先构建的 HTML 可以通过普通的静态托管或 CDN 提供。对于变化可预测的内容，这是一个很好的起点。请检查一次真实的构建需要多长时间，以及编辑人员在发布前如何查看草稿。

并不是每个静态系统都会在每次编辑后重建所有页面；增量构建的行为取决于所用工具。除了页面渲染之外，还要测试图片处理、内容获取和部署时间。

ISR 把已生成的输出与重新生成结合在一起。在 Next.js 的 Pages Router 中，重新验证间隔允许在间隔过去之后，由后续请求触发刷新；它并不是一个能保证在某一秒准时提供新内容的定时器。重新生成期间，缓存的输出可能仍然可见。

请在你实际使用的托管平台上，验证首次访问、重新生成失败和按需失效的行为。API 名称和支持情况因路由方式和框架版本而异。不要假设边缘运行时与 Node.js 部署支持相同的重新生成功能。

公开的商品描述通常可以容忍一定程度的过期，但最终的价格、库存和支付决定，必须在交易流程中进行核实。绝不能让一个旧的缓存页面成为购买的唯一可信来源。

可以。博客、商品目录和私有控制面板，可能有不同的渲染和缓存需求。请明确定义这些边界，并把运维模式的数量控制在团队能够测试的范围内。

当内容变化可预测时，预先构建或已缓存的公开 HTML 通常是很好的起点。正确的选择还取决于预览、发布延迟、集成和维护。请对完整页面做基准测试，包括图片和交互工作，而不只是响应的第一个字节。

不能。行为取决于框架和部署方式。在上文所述的 Next.js Pages Router 模型中，间隔过后的请求可以触发重新生成，而之前生成的响应可能仍然可用。请测试刷新失败、首次无缓存访问和按需失效。

私有或依赖权限的响应需要经过深思熟虑的边界，绝不能通过共享的公共缓存泄露出去。在返回受保护的信息之前，先完成授权。公开的内容页面和需要登录的账户页面，可以采用不同的渲染和缓存策略。