OpenNext项目中Page Router缓存失效问题分析与解决方案

问题背景

在使用OpenNext框架结合ISR(增量静态再生)功能时，开发者遇到了一个缓存失效问题。具体表现为：配置了10分钟缓存过期的页面，在实际运行中永远不会自动重新生成，即使等待时间远超设定的过期时间。只有当手动删除S3存储桶中的缓存文件时，才会触发重新生成。

问题现象

1. 页面缓存不会按照设定的10分钟过期时间自动失效
2. CloudFront缓存虽然过期，但Next.js服务端不会重新生成页面
3. DynamoDB表中没有预期的缓存记录
4. 响应头显示缓存状态为STALE，但不会触发重新验证

技术分析

缓存机制工作原理

OpenNext框架中，Page Router的缓存机制与App Router有所不同。Page Router不依赖DynamoDB来管理缓存状态，而是通过文件系统和HTTP头来控制缓存行为。

关键响应头分析

问题页面返回的响应头包含以下关键信息：

• x-nextjs-cache: STALE - 表示缓存已过期
• Cache-Control: s-maxage=2, stale-while-revalidate=2592000 - 设置缓存策略
• X-Cache: RefreshHit from cloudfront - 表示CloudFront正在处理请求

根本原因

经过排查，问题的主要原因是CloudFront缓存策略配置不完整。OpenNext使用x-prerender-revalidate头来控制页面的重新验证行为，但这个头默认不在CloudFront的允许头列表中，导致重新验证请求无法正确传递。

解决方案

1. 更新CloudFront配置

需要在CloudFront缓存策略中添加x-prerender-revalidate到允许的头部列表中。这个修改可以通过以下方式实现：

• 通过AWS控制台手动修改现有CloudFront分发
• 使用最新版本的SST框架(2.41.3及以上)，该版本已包含此修复

2. 构建环境注意事项

需要注意的是，OpenNext在Windows系统上构建时可能会遇到问题。建议在Linux或macOS环境下进行构建部署，以确保缓存机制正常工作。

最佳实践建议

1. 始终使用最新稳定版本的OpenNext和SST框架
2. 部署前验证CloudFront配置是否包含所有必要的允许头
3. 在非Windows环境下进行构建
4. 定期检查缓存头设置是否符合预期
5. 对于关键业务页面，考虑实现按需重新验证作为补充方案

通过以上措施，可以确保OpenNext项目的Page Router缓存机制按预期工作，实现可靠的ISR功能。