| 模式 | 渲染时机 | 适用 |
|---|---|---|
| CSR | 客户端 | 强交互后台 |
| SSR | 每次请求 | 个性化、实时数据、需 SEO |
| SSG | 构建时 | 内容稳定、高并发公开页 |
React 的 SSR 原理见 02-React 服务端渲染-从 SSR 到 hydrate，本章侧重工程选择。
现代框架支持细粒度缓存：
revalidate（如 export const revalidate = 60）：SSG 页面 60 秒后按需重渲；cache / fetch 的 next 选项；revalidateTag 在内容变更时主动失效。export const revalidate = 60; // 该路由最多每分钟重渲一次
export default async function Page() {
const data = await fetch('https://api.x/posts', { next: { tags: ['posts'] } }).then(r => r.json());
return <List data={data} />;
}loading.tsx + Suspense）降低 TTFB，配合 19-React Server Components 原理 的流式协议；SSR 的 hydration 风险（13-事件原理 提到的合成事件）、服务端/客户端不一致，是部署前必须验证的点。具体的平台部署（Vercel / 自建）请参考 Next.js 分类。
SSR 与 SSG 的取舍是「实时性 vs 性能/成本」。用 revalidate 做增量再生，用 CDN 扛静态流量，用边缘运行时跑 SSR——落地细节依赖框架，React 侧只需理解模型。