文章目录
目录导航
快速定位文章内容
正文
在 Next.js 里，我怎么判断页面该静态化、缓存，还是实时请求
很多人刚接触 Next.js 时，最容易卡住的不是组件写法，而是数据到底该怎么取。是 build 时提前生成，还是请求时动态拿？是让页面缓存一会儿，还是每次都请求最新数据？这件事如果判断错了，要么浪费性能，要么把本来该快的页面做得很重。
我先看数据变化频率
我现在做判断时，第一反应不是“这个页面重要吗”，而是“这份数据变得快不快”。
- 几天才变一次的内容
- 一小时更新一次的数据
- 几秒就可能变化的结果
变化频率不同，策略就应该不同。像博客文章、帮助文档、专题页，这类内容通常很适合提前生成。因为它们读多写少，用户更在意首屏快和 SEO 稳定。
适合静态化的页面
如果页面满足这些特征，我会优先往静态化方向想：
- 内容更新不频繁
- 对首屏速度要求高
- 希望被搜索引擎稳定抓取
- 页面结构基本固定
例如博客详情页、产品介绍页、落地页、教程页，通常都适合静态生成，必要时再搭配按周期重新验证。
export const revalidate = 3600
这个策略的核心不是“永远不更新”，而是让页面大多数时间都走缓存，只在合理周期内重建。
适合缓存但不必完全静态的页面
有一类页面不会频繁变化，但又不适合在构建阶段一次性全做完，比如价格页、排行榜、聚合列表、频道首页。
这时候我更喜欢让它在请求时生成，但带缓存策略。这样既能避免每次都重新跑完整逻辑，也能保证数据不是旧到离谱。
我会把这类页面理解成“准实时页面”：
- 数据会变，但不用秒级同步
- 页面访问量不低
- 生成成本相对高
- 可以接受短时间缓存
必须实时请求的页面
如果页面具备这些特征，我一般不会犹豫，直接按动态处理：
- 强依赖当前登录用户
- 数据变化非常频繁
- 每个请求看到的内容可能都不同
- 结果和 cookie、header、权限强相关
比如后台看板、订单状态、消息中心、搜索结果、个性化推荐，这些内容如果硬缓存，往往比“慢一点”更危险，因为它可能直接把旧数据或者别人的视图送到用户面前。
我常用的判断顺序
- 先看数据多久变一次。
- 再看用户是否需要立刻看到最新结果。
- 再评估页面生成成本是不是很高。
- 最后才决定是静态、缓存还是动态。
这个顺序能避免一种常见误区：只盯着技术名词选方案，却没先看业务到底需要“多新”的数据。
结语
Next.js 的价值，不只是把 SSR、SSG、ISR 这些缩写摆在一起，而是给了我们按业务场景选择渲染和缓存策略的空间。我的经验是，能静态就别实时，能缓存就别每次重算，只有真正需要最新结果的页面，才值得为“实时”付出额外成本。