SST 项目中 Next.js 应用部署与开发模式的资源管理问题解析

问题背景

在使用 SST（Serverless Stack）框架部署 Next.js 应用时，开发者可能会遇到一个令人困惑的现象：当执行 sst deploy 命令部署应用后，再运行 sst dev next dev 开发模式时，之前创建的 CloudFront 分发等资源会被自动删除。这种资源反复创建和删除的循环不仅影响开发体验，还会导致自动生成的 CloudFront 域名发生变化，进而影响依赖固定回调 URL 的认证流程。

核心问题分析

这种现象的根本原因在于开发者在同一个 Stage（阶段/环境）中混用了生产部署 (sst deploy) 和开发模式 (sst dev)。SST 框架在设计上对这两种模式有不同的资源管理策略：

1. 生产部署模式 (sst deploy)：

   • 会创建完整的生产环境资源，包括 CloudFront 分发、S3 存储桶、Lambda 函数等
   • 资源配置针对生产环境优化
   • 部署过程较慢，因为需要等待 CloudFront 分发完全部署

2. 开发模式 (sst dev)：

   • 会启动本地开发服务器
   • 移除生产环境资源以节省成本和提高开发效率
   • 创建轻量级的开发专用资源

解决方案

最佳实践是为生产和开发使用不同的 Stage：

1. 生产环境：

   • 使用 sst deploy --stage production 部署
   • 保留所有生产资源
   • 适合正式发布和测试环境

2. 开发环境：

   • 使用 sst dev --stage dev next dev 启动
   • 使用轻量级开发资源
   • 适合日常开发和调试

技术细节深入

当在同一个 Stage 中交替使用部署和开发命令时，SST 的资源管理逻辑会导致：

1. CloudFront 分发重建：

   • 每次 sst deploy 都会创建新的 CloudFront 分发
   • 分发 ID 和域名会变化
   • 部署等待时间较长（约4分钟）

2. 资源删除过程：

   • sst dev 会触发生产资源的删除
   • 包括 S3 存储桶、DynamoDB 表等
   • 删除操作耗时较长（约6分钟）

3. 认证流程影响：

   • 变化的 CloudFront 域名会导致 OAuth 等认证回调失败
   • 需要重新配置认证提供商中的回调 URL

实践建议

1. 环境隔离：

   • 严格区分生产、开发和测试环境
   • 为每个环境使用不同的 Stage 名称

2. 自定义域名：

   • 为生产环境配置固定域名
   • 避免依赖自动生成的 CloudFront 域名

3. CI/CD 集成：

   • 在 CI 流程中使用明确的 Stage 参数
   • 避免环境配置混淆

4. 本地开发：

   • 开发时使用 sst dev 命令
   • 充分利用本地模拟和热重载功能

总结

理解 SST 框架中不同命令对资源的管理方式，是高效使用该框架的关键。通过合理规划环境和使用不同的 Stage，开发者可以避免资源被意外删除或重建的问题，同时获得更好的开发体验和更稳定的生产环境。记住，生产部署和开发模式设计目的不同，将它们分开使用才能发挥各自的最大价值。