核心价值清晰声明每个段的静态或动态特性,避免不可预期的缓存与再验证行为。使用 `revalidate` 与 `fetch` 的 `cache/next` 选项形成一致的再验证策略。声明动态/静态边界// app/posts/[id]/page.tsx (RSC) export const dynamic = 'force-dynamic' // 此段强制动态渲染 export default async function Page({ params }: { params: { id: string } }) { const post = await fetch(`https://api.example.com/posts/${params.id}`, { cache: 'no-store', }).then(r => r.json()) return <pre>{JSON.stringify(post, null, 2)}</pre> } // app/blog/page.tsx (RSC) export const dynamic = 'force-static' // 此段强制静态并可再验证 export const revalidate = 300 export default async function Blog() { const list = await fetch('https://api.example.com/blog', { next: { revalidate: 300, tags: ['blog'] }, }).then(r => r.json()) return <ul>{list.map((x: any) => <li key={x.id}>{x.title}</li>)}</ul> } 与 fetch 选项协同动态段优先 `cache: 'no-store'`;静态段使用 `next.revalidate/tags` 或 `cache: 'force-cache'`。使用 `tags` 与按需 `revalidateTag` 保持列表与详情的一致刷新。// app/api/revalidate/route.ts export const runtime = 'edge' export async function POST() { // revalidateTag('blog') // 在实际项目中触发标签刷新 return Response.json({ ok: true }) } 治理建议对包含用户特定数据的段使用动态渲染,避免缓存泄漏。对公共列表或 CMS 内容使用静态+再验证,兼顾性能与更新频率。结论明确的段级边界与统一的再验证策略是稳定可预期的数据获取基础,能显著降低缓存相关故障与性能波动。

发表评论 取消回复