Next.js 的缓存问题本质是页面类型没分清
很多 Next.js 项目出问题，不是因为缓存能力不够，而是团队没有先定义页面类型。营销页、博客文章、商品详情、后台列表、用户中心，看起来都只是页面，但它们对缓存的要求完全不同。
静态内容希望尽量缓存，后台数据希望及时刷新，用户态页面不能被公共缓存。把这些页面用同一种策略处理，迟早会出现“我改了数据但页面不变”或“用户看到别人状态”的问题。
先按三类页面设计
第一类是稳定公开页，例如文档、博客、落地页。这类页面适合静态生成或较长缓存，发布内容后通过重新构建或显式 revalidate 更新。
第二类是公开但经常变化的页面，例如商品列表、价格页、库存页。这类页面要把缓存时间和业务容忍度写清楚。价格和库存通常不能长缓存，筛选列表也要注意查询参数。
第三类是登录后页面，例如订单、后台、个人资料。这类页面优先保证正确性，不要为了性能轻易缓存完整响应。
Server Action 后要考虑刷新
用户提交表单后，如果页面仍展示旧数据，通常不是提交失败，而是缓存没有被刷新。更新数据后要明确刷新哪个路径或哪组数据。不要依赖用户手动刷新浏览器来看到结果。
对团队来说，最好建立一个约定：任何写操作都必须说明它影响哪些读取页面。这样代码评审时能看出是否遗漏了缓存刷新。
动态页面不要假装静态
如果页面依赖当前用户、Cookie、请求头、实时库存或权限判断，就不要把它当成普通静态页优化。性能可以通过分页、流式渲染、局部缓存和接口优化解决，但不能牺牲数据正确性。
缓存策略应写进代码旁边或团队文档里。未来新人维护时，能知道这个页面为什么缓存 60 秒，为什么另一个页面完全不缓存。
调试时看响应而不是猜
排查缓存问题时，先看请求是否真的打到服务端，再看响应头、构建输出和数据更新时间。不要只凭“页面没变”判断。浏览器缓存、路由缓存、服务端缓存、CDN 缓存都可能参与其中。
总结
Next.js 15 更适合显式设计缓存。先分清页面类型，再决定缓存和刷新方式。公开稳定页追求速度，动态业务页追求正确性，用户态页面保持谨慎，这样才能减少线上刷新混乱。
页面分类先于缓存配置
Next.js 缓存问题的根源，很多时候不是 API 不熟，而是页面类型没分清。可以先把页面分成静态内容页、半动态列表页、强实时用户页三类。静态内容页适合缓存，列表页适合设置明确的 revalidate，用户相关页面则应避免被误缓存。
每个页面最好写清楚数据来源和更新频率。比如文章详情一天变化很少，分类列表发布后需要刷新，登录后的账户页则必须实时读取。先有这张清单，再配置缓存策略，出错概率会低很多。
验证方式
上线前用不同用户、不同浏览器和无登录状态分别访问，检查响应头、页面内容和更新时间。尤其要确认后台更新文章后，前台列表和详情页能在预期时间内刷新。缓存策略不是写完就结束，必须和发布流程一起验证。