SST项目中NextjsSite构建服务器缓存策略的演进与实践

在SST框架的演进过程中，NextjsSite组件的服务器缓存策略配置方式发生了变化。本文将从技术实现角度分析这一变化，并分享实际项目中的解决方案。

缓存策略的背景与重要性

在现代Web应用中，合理的缓存策略对性能优化至关重要。SST框架通过CloudFront CDN为Next.js应用提供边缘缓存能力，其中服务器端渲染(SSR)页面的缓存策略需要特别设计。

原有实现方式的变化

早期版本中，SST提供了buildDefaultServerCachePolicyProps()方法来构建默认的服务器缓存策略。但在新版本中，这一方法已被移除，开发者需要自行配置完整的缓存策略。

自定义缓存策略的实现

在实际项目中，我们可以参考SSRSite和NextjsSite的原有实现，结合项目需求进行定制：

{
  cdk: {
    distribution: {
      defaultBehavior: {
        responseHeadersPolicy: cf.ResponseHeadersPolicy.SECURITY_HEADERS,
      },
    },
    serverCachePolicy: new cf.CachePolicy(stack, 'ServerCache', {
      queryStringBehavior: cf.CacheQueryStringBehavior.all(),
      headerBehavior: cf.CacheHeaderBehavior.allowList(
        'x-open-next-cache-key',
        'accept-language'
      ),
      cookieBehavior: cf.CacheCookieBehavior.allowList('appSession', 'hubspotutk'),
      defaultTtl: cdk.Duration.days(0),
      maxTtl: cdk.Duration.days(365),
      minTtl: cdk.Duration.days(0),
      enableAcceptEncodingBrotli: true,
      enableAcceptEncodingGzip: true,
      comment: 'SST server response cache policy',
    }),
  },
}

关键配置解析

1. 安全头设置：通过SECURITY_HEADERS添加了基本的安全头部
2. 查询参数处理：允许所有查询参数影响缓存键
3. 头部处理：
   • 保留x-open-next-cache-key用于OpenNext框架的缓存控制
   • 添加accept-language支持多语言场景
4. Cookie处理：
   • 包含appSession用于身份验证
   • 包含hubspotutk支持HubSpot跟踪
5. 压缩支持：启用Brotli和Gzip压缩
6. TTL设置：
   • 默认TTL为0天
   • 最大TTL为365天
   • 最小TTL为0天

最佳实践建议

1. 根据应用特点调整：不同应用对缓存的需求不同，应根据实际场景调整
2. 关注安全头部：始终确保包含基本的安全头部
3. 考虑国际化：多语言应用需要正确处理语言相关的头部
4. 身份验证处理：确保认证相关的Cookie被正确处理
5. 监控与调优：部署后监控缓存命中率，持续优化策略

总结

SST框架的演进使得开发者需要更深入地理解缓存策略的配置。通过自定义策略，我们可以更好地控制应用的行为，在保证功能完整性的同时获得最佳性能。这种变化虽然增加了配置的复杂性，但也提供了更大的灵活性，使开发者能够根据具体需求进行精细调整。