理解检验

营销页:内容稳定、读者多,SSG(或 "use cache" 缓存数据)整页进 CDN,首字节最近、服务器成本最低。

千人千面信息流:没有可共享的静态产物,SSR(connection() 声明等请求)每请求现算;硬上 PPR 也抽不出静态壳,只会退化成它。

慢接口后台页:壳可以静态、数据慢,Streaming(按区块包 Suspense)或 PPR;静态壳先吐,慢区块分段补出,用户不用盯着白屏等最慢的那个接口。

同一个站点三种页面各占一格是正常的 —— 渲染策略按路由甚至按组件混用,不是全站一个开关。

回到专题:渲染光谱梳理

整页都动态(个性化信息流、实时仪表盘):没有静态壳可抽,PPR 退化为普通 Streaming SSR,白添一套缓存声明。

整页都静态(文档、营销页):SSG / "use cache" 本来就够快,动态洞是多余的复杂度。

团队没有缓存失效纪律:PPR 的静态部分靠显式 "use cache" + cacheLife + cacheTag 声明,每个缓存条目都要想清新鲜度与失效方式,粗放使用会积累 stale 事故。

回到专题:PPR 与 Cache Components

revalidate = 60 → 在取数函数/组件上写 "use cache" + cacheLife({ revalidate: 60 }),按需再补 cacheTag。缓存的粒度从「整页」变成「作用域」,一页里可以同时存在多个不同新鲜度的缓存块。

force-dynamic → 什么都不写:取数默认就是请求时动态;要声明「整页都等请求到达再渲染」时用 connection()。

为什么反过来:旧模型要防止「忘记加 no-store 就被缓存」的隐式行为;新模型把缓存变成显式 opt-in,不写指令的部分天然不会误进缓存。

回到专题:PPR 与 Cache Components

cacheComponents 下构建期会尝试预渲染静态壳:渲染走到第一个 Suspense 边界为止,边界外的部分冻结成可进 CDN 的产物。

cookies()、未缓存的 fetch 这类请求时数据在构建期不存在 —— 如果它们出现在 Suspense 边界之外,构建器无法决定壳里该放什么,直接报错(Uncached data was accessed outside of <Suspense>)。

所以边界回答的是「静态壳到哪里为止」:洞内是每请求现算的动态区,洞外必须能在没有任何请求信息的前提下渲染出来。

回到专题:PPR 与 Cache Components

○ 完全静态(含「壳 + 缓存数据」),可直接由 CDN 吐出;◐ Partial Prerender,壳预渲染、动态洞请求时经 Suspense 流式补出;ƒ 每请求动态,本站的 /api/* Route Handler 都在这一格。

Revalidate / Expire 两列直接展示各路由的缓存窗口 —— 比如 /rendering/isr 是 ○ 且 Revalidate 为 1m,说明数据整份进了 "use cache" + cacheLife({ revalidate: 60 })。

验收姿势:改完缓存声明后看构建输出,某页该是 ◐ 却变成 ƒ,往往是有动态数据漏出了 Suspense 洞。

回到专题:PPR 与 Cache Components

不会。到期后的第一个请求拿到的是旧缓存(stale),同时触发后台重建(revalidate);再之后的请求才看到新产物。这是 ISR 与 revalidateTag 共享的 SWR 语义 —— 读者晚一拍看到新值,换的是任何请求都不用等重建。

如果业务要求「改完立即读到新值」(read-your-own-writes,比如表单提交后的响应里就要带新数据),时间驱动与 SWR 都不够用,要用 Server Action 里的 updateTag 立即过期。

回到专题:ISR 与静态再生按需失效实战

各自包边界时:静态壳(页头、骨架)先行吐出,三个洞按各自完成顺序流式补出,3s 的区块不阻塞 0.5s 的。TTFB 由壳决定,不由最慢的洞决定。

只用一个边界包住三个:边界要等内容齐全才能补出,整页退化成「壳 + 一次 3s 后的整块补出」,分段到达消失。

反过来说,边界也不是越碎越好:同一区块里必须一起出现才有意义的内容(标题和它的时间戳)应共用一个边界,避免半截 UI。

回到专题:Streaming SSR 与 Suspense 粒度