SST项目开发模式下Lambda架构配置的特殊处理

在SST框架的实际开发过程中，开发者可能会遇到一个有趣的现象：当在函数配置中明确设置architecture: "arm64"时，使用sst dev命令启动的开发模式与使用sst deploy进行正式部署时，Lambda函数的架构表现会有所不同。

现象描述

开发者在配置文件中为Lambda函数指定ARM64架构后，通过以下两种方式部署时会发现：

1. 使用sst deploy命令部署时，AWS控制台中显示的Lambda函数确实采用了ARM64架构
2. 使用sst dev启动开发模式时，检查AWS上的Lambda函数却显示架构配置未被应用

技术原理

这种现象实际上是SST框架的刻意设计。在开发模式下，SST采用了一种特殊的"本地代理"机制：

1. 云端部署的Lambda函数本质上是一个转发代理
2. 实际执行发生在开发者的本地机器上
3. 通信通过AWS IoT Core服务实现调用转发

这种设计带来了几个显著优势：

• 极快的本地开发反馈循环
• 避免频繁的云端部署
• 节省云资源使用成本

架构配置的差异处理

由于开发模式下Lambda的实际执行环境是本地机器，而非云端，因此：

• 架构配置在开发模式下被有意忽略
• 正式部署时才会应用配置的架构参数
• 这种处理方式确保了开发体验的一致性

最佳实践建议

对于需要在开发阶段测试特定架构的开发者，建议：

1. 重要的架构相关测试应通过正式部署进行
2. 开发阶段主要关注业务逻辑验证
3. 可利用SST的阶段(stage)功能区分不同环境

理解这一设计原理有助于开发者更高效地利用SST框架进行无服务器应用开发，避免在开发过程中对架构配置产生困惑。