2025年末 Serverless Framework 现状：迁移还是坚守？
引言：一个时代的转折点
如果你是一位 AWS 无服务器架构的实践者，2025年末这个时间节点可能让你感到些许焦虑。曾经风靡一时的 Serverless Framework 正站在命运的十字路口——v3 版本已进入 EOL（End of Life）阶段，而 v4 版本开始采用商业收费模式。
最近在技术社区中，一位开发者分享了他们公司的真实处境：约 40 个微服务中，三分之一已迁移到 CDK，其余仍在使用 Serverless Framework 3.xx。这个场景在业界极具代表性——既有对老工具的依恋，又有对未来的不确定。
作为一名经历过多次技术栈迁移的云架构师，我想和大家深入探讨这个问题：在 2026 年，我们该如何规划无服务器部署工具的技术路线？
问题分析：Serverless Framework 为何走到今天
商业模式的必然转型
Serverless Framework 的收费决策并非突然之举。作为一个开源项目，长期依赖社区贡献和风险投资难以持续。v4 的商业化是团队寻求可持续发展的必然选择。正如原帖作者所言：”如果他们能从中盈利，那是他们应得的。”
技术债务的累积
继续使用 EOL 版本意味着：
- 安全风险：不再有安全补丁更新
- 兼容性问题：新版 AWS 服务可能无法支持
- 社区萎缩：插件生态逐渐停止维护
- 招聘困难：新人可能不熟悉过时工具
插件生态的困境
Serverless Framework 最大的优势之一是其强大的插件系统。原帖作者提到他开发了 OpenAPI 定义相关的插件，并正在开发 Arazzo 插件。这些定制化能力在迁移时往往是最大的痛点——如何在新平台上重现这些功能？
解决方案探讨：四条主流路径
方案一：坚守 Serverless Framework v3
社区中有相当一部分开发者选择继续使用 v3。正如一位开发者所说：”坚持使用 v3，没有迁移计划。它有太多有用的功能和插件，目前没有替代品能取代。”
✅ 优点：
- 零迁移成本
- 团队无需学习新工具
- 现有插件和工作流继续可用
- 适合使用 bref.sh 等特定生态的项目
❌ 缺点：
- 技术债务持续累积
- 长期风险不可控
- 可能错过新特性
适用场景：稳定运行的遗留系统、短期项目、重度依赖特定插件的团队
方案二：迁移到 AWS CDK
CDK 是目前最主流的迁移目标。一位开发者分享道：”今年早些时候我完成了全面替换，转向 CDK。本来一直在拖延，但 Claude Code 让这个过程轻松了很多。”
// CDK Lambda 函数定义示例
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';
const handler = new lambda.Function(this, 'MyFunction', {
runtime: lambda.Runtime.NODEJS_18_X,
code: lambda.Code.fromAsset('lambda'),
handler: 'index.handler',
});
const api = new apigateway.RestApi(this, 'MyApi');
api.root.addMethod('GET', new apigateway.LambdaIntegration(handler));✅ 优点：
- AWS 官方支持，长期维护有保障
- 完整的 TypeScript/Python 类型支持
- 可管理所有 AWS 资源，不仅限于 Lambda
- 与 CloudFormation 深度集成
❌ 缺点：
- 学习曲线较陡
- 代码量通常比 serverless.yml 多
- 本地开发体验不如 Serverless Framework
适用场景：中大型团队、需要管理复杂 AWS 资源、追求长期稳定性
方案三：采用 SST（Serverless Stack）
SST 是近年来崛起的新星，专注于提供更好的开发体验。有开发者表示：”我们迁移到了 SST，它服务得很好。”
// SST 配置示例
export default {
config() {
return {
name: "my-app",
region: "us-east-1",
};
},
stacks(app) {
app.stack(function API({ stack }) {
const api = new Api(stack, "api", {
routes: {
"GET /": "functions/handler.main",
},
});
});
},
};✅ 优点：
- 基于 CDK 构建，兼具灵活性
- 出色的本地开发体验（Live Lambda Development）
- 配置简洁，接近 Serverless Framework 的简洁度
- 活跃的社区和快速迭代
❌ 缺点：
- 相对年轻，生态不如 CDK 成熟
- 部分高级场景可能需要回退到原生 CDK
- 版本更新较快，可能有 breaking changes
适用场景：新项目、重视开发体验的团队、全栈应用
方案四：Terraform + 自定义脚本
对于已有 Terraform 基础设施的团队，这是一个自然的选择。一位开发者分享：”我已经开始用 Terraform 管理基础设施，并用内部脚本管理本地设置和部署。它与我们其他 TF 基础设施集成得很好。”
✅ 优点：
- 多云支持，不锁定 AWS
- 与现有 Terraform 基础设施无缝集成
- 成熟稳定，企业级支持
❌ 缺点：
- 需要额外开发部署脚本
- 本地开发体验需要自行构建
- HCL 语法对部分开发者不友好
适用场景：多云环境、已有 Terraform 投资的团队、DevOps 成熟度高的组织
最佳实践与专业建议
决策框架：如何选择适合你的方案
基于我的实战经验，建议从以下维度评估：
- 团队规模与技术能力
- 小团队（<5人）：SST 或继续 v3
- 中型团队（5-20人）：CDK 或 SST
- 大型团队（>20人）：CDK 或 Terraform
- 现有技术栈
- 已有 Terraform：优先考虑 Terraform 方案
- 纯 AWS 环境：CDK 是最佳选择
- 追求开发效率：SST 值得尝试
- 项目生命周期
- 短期项目（<1年）：继续 v3 或快速迁移到 SST
- 长期项目（>3年）：投资 CDK 是值得的
迁移策略：渐进式而非一刀切
参考原帖公司的做法——40 个微服务中逐步迁移三分之一——这是一个明智的策略：
阶段 1：新项目全部使用新工具（CDK/SST）
阶段 2：识别高风险/高维护成本的服务优先迁移
阶段 3：稳定运行的遗留服务最后处理或保持现状善用 AI 工具降低迁移成本
正如社区中提到的，AI 编程助手可以显著降低迁移痛苦。将 serverless.yml 转换为 CDK 代码、重写插件逻辑等重复性工作，AI 可以完成大部分初始工作，人工只需审查和调优。
我的最终建议
如果让我为不同场景给出具体建议：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 全新项目 | SST 或 CDK | 没有历史包袱，直接选择有未来的工具 |
| 大量遗留服务 | CDK + 渐进迁移 | 官方支持，长期稳定，值得投资 |
| 多云/混合云 | Terraform | 统一工具链，避免厂商锁定 |
| 预算有限的小团队 | 继续 v3 + 观望 | 短期内风险可控，等待生态成熟 |
总结
Serverless Framework 的商业化转型标志着一个时代的结束，但也开启了新的可能性。无论选择哪条路径，关键是做出有意识的决策，而非被动等待。
技术选型没有绝对的对错，只有适合与否。希望这篇文章能帮助你在 2026 年的技术规划中做出更明智的选择。记住：最好的迁移时机是昨天，其次是今天。
需要优化您的 AWS 架构？ 欢迎在评论区分享您的 Serverless Framework 迁移经验，或者您正在使用的替代方案。让我们一起探讨最佳实践！
