Next.js增量静态再生中revalidate流程的工作机制及计时规则疑问

核心运行规则 #

Next.js 中 getStaticProps 配置的 revalidate 参数，是基于页面缓存版本做中心化计时的，完全不会为每个独立用户/请求单独计算重建间隔，本质是遵循 stale-while-revalidate 的缓存更新模型。

完整流程拆解（以配置 revalidate: 60 为例） #

整个逻辑按单份缓存版本的生命周期推进：

• 页面首次构建完成后，会在服务端/边缘缓存节点存储一份静态页面版本，同时为这份版本记录两个关键信息：版本生成的时间戳、版本状态（可直接服务/正在后台重建）
• 所有指向该页面的请求，只要检测到当前缓存版本距离生成时间还没达到60秒阈值，无论请求来自哪个用户，都会直接返回这份现成的缓存，不会触发任何重建动作
• 当任意一个请求进来时，检测到当前缓存版本的存活时间已经满60秒，Next.js 不会让这个用户等待重建完成，而是立即返回当前存储的旧缓存版本，同时在后台异步触发该页面的重新构建流程
• 后台重建完成后，旧的缓存版本会被新生成的版本替换，新的版本会重新记录自己的生成时间戳，开启下一轮60秒的计时周期。

对应疑问场景的明确解答 #

• 不存在为单个用户单独计算重建间隔的逻辑。整个版本的计时起点是这份缓存生成完成的时刻，所有访问这份缓存的用户共享同一个计时周期，你所担心的“每个独立请求启动专属60秒间隔”的运行模式，在ISR机制里是完全不会触发的。
• 用户B不会拿到和用户A独立的缓存版本、单独走自己的60秒等待流程。只要当前缓存版本还在有效期内，B拿到的和A是完全同一份缓存、同一个计时基准，不会给B单独开通计时流程。
• 重建过程也不会出现多请求重复触发的问题：哪怕缓存到时间的窗口期内有几十上百个用户同时请求，这些用户拿到的都是触发重建前的最后一份旧缓存，不会阻塞等待重建完成，也不会因为多个用户请求就多次重复触发页面重建。

内容的提问来源于stack exchange，提问作者Timmske