OpenNext项目静态资源缓存问题解析

在部署基于Next.js的应用时，静态资源缓存是一个需要特别注意的问题。最近在使用OpenNext配合SST部署到AWS时，发现了一个值得关注的缓存行为现象。

问题现象

当使用OpenNext和SST将Next.js初始项目部署到AWS时，开发者观察到vercel.svg、favicon.ico和next.svg等静态资源出现了双重加载的情况。具体表现为：

1. 这些资源首先从本地磁盘缓存加载（这是预期的正常行为）
2. 随后又意外地从CloudFront再次请求相同的资源

这种双重加载行为在Vercel平台上部署时并未出现，仅在AWS+SST+OpenNext的组合部署环境中发生。

技术背景分析

这种现象实际上与SST框架的资源缓存配置有关。在SST的底层实现中，对于SSR站点（如Next.js应用）的静态资源处理有一套默认的缓存策略。

SST框架默认会对静态资源文件设置缓存头信息，这包括两类文件：

1. 带版本哈希的文件（如main.abc123.js）
2. 不带版本的文件（如favicon.ico）

解决方案

针对这个问题，SST提供了灵活的配置选项。开发者可以通过以下方式自定义非版本化文件的缓存头：

assets: {
  nonVersionedFilesCacheHeader: "自定义的缓存头值"
}

这个配置项允许开发者精确控制那些不包含版本哈希的静态资源的缓存行为。通过适当设置，可以避免不必要的双重请求，优化应用性能。

最佳实践建议

1. 对于频繁更新的非版本化静态资源，建议设置较短的缓存时间或禁用缓存
2. 对于几乎不会变化的静态资源，可以设置较长的缓存时间
3. 在开发环境中，可以考虑禁用缓存以便于调试
4. 生产环境中，应根据资源更新频率合理配置缓存策略

通过理解这些缓存机制并合理配置，开发者可以确保静态资源既能够被有效缓存，又不会出现不必要的重复请求，从而提升应用的整体性能表现。