使用 unstable_cache + revalidateTag 组合实现 Next.js 服务端函数缓存，并了解 fetch 缓存和多个实例间共享缓存等。

基于数据函数的缓存 unstable_cache

https://nextjs.org/docs/app/api-reference/functions/unstable_cache

适合服务端数据读取，如直接读数据库或聚合多源数据的服务端函数，配合 tags 与 revalidate 实现自动失效与定时刷新。

典型结构：

return unstable_cache(
  async () => getPublicPostList(input),
  ['public-post-list', String(input.page), String(input.count), String(version)],
  { revalidate: 300, tags: ['public-posts'] },
)();

关键点：

• cache key 需要包含业务参数与版本号，保证多实例下能强制刷新
• tags 用于数据变更时统一失效
• revalidate 作为兜底的时间刷新

主动失效缓存 revalidateTag

https://nextjs.org/docs/app/api-reference/functions/revalidateTag

当写入数据后主动失效缓存。

• 第一个参数是需要失效的 tags ，支持传多个。
• 第二个参数是 缓存“profile” （缓存策略配置）的名称，用来决定 tag 被 revalidate 后的行为。
  • max ：更偏向 stale‑while‑revalidate ，用户更可能先拿到旧数据，后台更新，适合读多写少、对瞬时一致性要求不高的场景。
  • default ：取决于框架默认策略（通常也偏 SWR，但具体行为受版本和配置影响），更保守。

写入数据后触发，如：

• 更新文章后失效公共文章与专栏缓存
• 更新专栏关联后失效专栏缓存

fetch 缓存和 revalidatePath 页面级失效（了解）

还有一种常见的缓存用法是 fetch 级别缓存与刷新：

• 在 Server Component 或 Route Handler 中使用 fetch 的 cache/next.revalidate 控制
• 适合通过 HTTP 请求获取数据的场景，依赖 Next.js 内建的请求缓存与 tag/revalidate
• 粒度是“请求级别”，更容易和外部 API 或内部 HTTP 接口对齐

await fetch(url, { cache: 'force-cache' });
await fetch(url, { cache: 'no-store' });
await fetch(url, { next: { revalidate: 300, tags: ['posts'] } });

fetch 缓存失效：

• 按路径失效 revalidatePath：适合页面级缓存失效
  • 粒度是“路由级别”，主要影响对应路径的页面渲染缓存
  • 维护成本低、心智负担小
• 可以通过 revalidateTag 实现”请求级别“的粒度失效

import { revalidatePath } from 'next/cache';
revalidatePath('/posts');

多个实例间共享缓存（了解）

默认的内存缓存是与每个 Next.js 进程隔离的。如果运行多个服务器或容器，每个实例都会有自己的缓存，不会与其他服务共享，重启时缓存会丢失。

可以使用 cacheHandlers 配置自定义缓存的存储实现，配置为使用远程缓存/配置到Redis中等，

• https://nextjs.org/docs/app/api-reference/config/next-config-js/cacheHandlers
• https://nextjs.org/docs/app/api-reference/directives/use-cache-remote