Next.js 的缓存问题本质是页面类型没分清

很多 Next.js 项目出问题，不是因为缓存能力不够，而是团队没有先定义页面类型。营销页、博客文章、商品详情、后台列表、用户中心，看起来都只是页面，但它们对缓存的要求完全不同。

静态内容希望尽量缓存，后台数据希望及时刷新，用户态页面不能被公共缓存。把这些页面用同一种策略处理，迟早会出现“我改了数据但页面不变”或“用户看到别人状态”的问题。

先按三类页面设计

第一类是稳定公开页，例如文档、博客、落地页。这类页面适合静态生成或较长缓存，发布内容后通过重新构建或显式 revalidate 更新。

第二类是公开但经常变化的页面，例如商品列表、价格页、库存页。这类页面要把缓存时间和业务容忍度写清楚。价格和库存通常不能长缓存，筛选列表也要注意查询参数。

第三类是登录后页面，例如订单、后台、个人资料。这类页面优先保证正确性，不要为了性能轻易缓存完整响应。

Server Action 后要考虑刷新

用户提交表单后，如果页面仍展示旧数据，通常不是提交失败，而是缓存没有被刷新。更新数据后要明确刷新哪个路径或哪组数据。不要依赖用户手动刷新浏览器来看到结果。

对团队来说，最好建立一个约定：任何写操作都必须说明它影响哪些读取页面。这样代码评审时能看出是否遗漏了缓存刷新。

动态页面不要假装静态

如果页面依赖当前用户、Cookie、请求头、实时库存或权限判断，就不要把它当成普通静态页优化。性能可以通过分页、流式渲染、局部缓存和接口优化解决，但不能牺牲数据正确性。

缓存策略应写进代码旁边或团队文档里。未来新人维护时，能知道这个页面为什么缓存 60 秒，为什么另一个页面完全不缓存。

调试时看响应而不是猜

排查缓存问题时，先看请求是否真的打到服务端，再看响应头、构建输出和数据更新时间。不要只凭“页面没变”判断。浏览器缓存、路由缓存、服务端缓存、CDN 缓存都可能参与其中。

总结

Next.js 15 更适合显式设计缓存。先分清页面类型，再决定缓存和刷新方式。公开稳定页追求速度，动态业务页追求正确性，用户态页面保持谨慎，这样才能减少线上刷新混乱。