本文作者分享了在尝试使用 Next.js 的 Cache Component 时遇到的诸多问题。从官网文档错误、`use cache` 的实际应用限制、ISR 功能缺失，到 `middleware.ts` 重命名为 `proxy.ts` 在 Windows 下引发的兼容性问题。此外，作者还指出 `cacheComponent` 与 `dynamic='force-static'` 的行为不一致，导致动态内容被错误缓存，以及在开发环境 (`dev`) 下 `use cache` 引起崩溃但生产环境正常的情况。最后，作者提醒使用 `next-intl` 等路由基础的国际化方案的项目，在升级前需注意兼容性问题，并建议暂缓升级或谨慎使用 `cacheComponent`。

📝 **文档与实际不符：** 作者指出 Next.js 官方文档中关于 `use cache` 的示例存在错误，声称非 `async` 函数可用，但实际并非如此，导致原有的共享组件写法需要修改。同时，ISR 等缓存相关文档内容尚未更新，无法在 `cacheComponent` 中使用。

💻 **跨平台兼容性问题：** `middleware.ts` 被重命名为 `proxy.ts` 后，在 Windows 环境下测试不充分，导致构建后 `proxy.ts` 功能完全失效，仅在改回 `middleware.ts` 后才恢复正常。此问题已在 v16.0.1 版本中修复。

🔄 **行为不一致与缓存错误：** 使用 `cacheComponent` 替代 `dynamic='force-static'` 后，发现两者行为不一致。动态内容被强制返回 `cache-control:no-store`，即使调试日志显示已走缓存。而原先的 `force-static` 则能正确返回 `s-maxage` 和 `swr`。

🐞 **开发与生产环境差异：** 在持续修改代码并构建以观察生产环境缓存情况时，作者遇到了开发环境 (`dev`) 下 `use cache` 导致崩溃的问题，尽管生产环境运行正常。此外，在 v15 版本中，所有 SSG 页面都变成了 PPR，即使添加 `use cache` 也无法恢复为 SSG。

🌐 **国际化方案兼容性：** 对于使用了如 `next-intl` 等基于路由的国际化方案的项目，作者提醒这些方案可能尚未完全兼容 Cache Component。若不及时在 `setRequestLocale` 中设置 `locale`，`next-intl` 会读取 cookie，迫使所有组件添加 `Suspend` 或 `use cache`。

这几天对那个 cache component 感兴趣，就找了个之前的项目试了一下。

结果像捅了 bug 窝子一样。

首先是官网文档上一堆错误，他们的 use cache 例子给了非 async 函数可用，但是实际不可用，所以之前那种 shared component 的写法都得改（不写 use client ，但是用 hook 的方式）。ISR 等文档内容在 cacheComponent 无法使用，还没更新。

middleware.ts 改名成了 proxy.ts, 但是没测试 windows ，导致 build 之后，windows 下整个 proxy.ts 功能消失（换成 middleware.ts 又可用了）。 确认 16.0.1 修复

用文档的 cacheComponent 取代 dynamic='force-static'后发现两者行为不一致，用那个写法的动态内容全返回了 cache-control:no-store,打 debug 日志是走了缓存。原先 force-static 会返回 s-maxage 和 swr

一直改代码 build ，观察生产环境的缓存情况，结果发现跑 dev 报错... ...某些情况写"use cache"，dev 就会挂掉，但是生产没问题。😂

15 时候是 SSG 的 page 全变成了 PPR ，并且加 use cache 也变不回 SSG 。

如果你项目里用了 next-intl 之类 route base 的 i18n,他们可能还没兼容好。next-intl 最好拿到 locale 都设置一下 setRequestLocale,不然它会去读 cookie ，导致所有的组件都要加 Suspend 或者 use cache 。

这是我就试了 2 天发现的...这特么...

大家打算升级的缓一缓啊。。。或者不要开 cacheComponent