2026年，Serverless（AWS Lambda、Cloudflare Workers、Vercel Functions）用户突破500万，是2020年的5倍。Serverless的"承诺"很吸引人：零运维——你不需要管理服务器，只需要写代码，部署到云厂商的Serverless平台，平台自动处理弹性伸缩、负载均衡、监控告警。
但2026年，越来越多Serverless用户发现：Serverless不是"零运维"，而是"运维转移到了云厂商"。你要学习的不是"运维服务器"，而是"运维Serverless平台"。后者的复杂度，不亚于前者。
金句：Serverless的"承诺"是"零运维"，“现实"是"新运维”。你不需要管理服务器，但你需要管理"冷启动"、“超时”、“并发限制”、“成本爆炸”、“厂商锁定”。这些是Serverless的"新运维"，比传统的"运维服务器"更复杂。
Serverless的"阴暗面"
阴暗面一：冷启动。 你的Serverless函数，如果一段时间没有被调用，会被"冷冻"（关闭）。下一次调用时，需要"冷启动"——重新加载函数代码、初始化数据库连接、加载依赖库。冷启动的延迟，从100ms到10秒不等。对于"低延迟"业务（如API服务），冷启动是"致命"的。
阴暗面二：调试困难。 传统服务器，你可以登录服务器，查看日志，调试代码。Serverless平台，你无法"登录"服务器（因为服务器是共享的，不属于你）。你只能通过"日志"来调试——但日志是"黑盒"的，你只能看到云厂商"允许你看到"的信息。
阴暗面三：并发限制。 Serverless平台对"并发数"有限制——AWS Lambda的初始并发限制是1000，Cloudflare Workers的并发限制是100。如果你的业务突然爆发（如秒杀、抢购、网红推荐），超过并发限制，请求被拒绝。
阴暗面四：成本爆炸。 Serverless的"按次付费"模式，在"低流量"时便宜，在"高流量"时昂贵。一个"高流量"的API，在Serverless上的成本可能是传统服务器的5-10倍。
阴暗面五：厂商锁定。 你的代码，部署在AWS Lambda上，用的是AWS的"专属API"（如S3、DynamoDB、SQS）。如果想把代码迁移到Azure Functions或Google Cloud Functions，需要重写大量代码。Serverless的"迁移成本"，比传统服务器高得多。
金句：Serverless的"阴暗面"是"冷启动"、“调试困难”、“并发限制”、“成本爆炸”、“厂商锁定”。这五个"阴暗面"，每一个都能让你从"Serverless爱好者"变成"Serverless受害者"。
2026年Serverless的"最佳实践"
实践一：不把"核心业务"放在Serverless上。 Serverless适合"非核心、低延迟容忍、流量波动大"的业务——如定时任务、图片处理、消息推送。不适合"核心业务"——如订单系统、支付系统、用户系统。核心业务，放在"传统服务器"或"容器"上。
实践二：使用"混合架构"。 核心业务用传统服务器，非核心业务用Serverless。“混合架构"是2026年的最佳实践。
实践三：保持"厂商中立”。 尽量使用"开源Serverless框架"（如OpenFaaS、Knative），而不是"云厂商专属"的Serverless。开源Serverless，可以部署在任何云平台上，避免厂商锁定。
金句：Serverless不是"银弹"，它是"工具箱"中的"一把工具"。用对场景，事半功倍。用错场景，事倍功半。
结语
2026年，Serverless已经从"概念炒作"进入"务实落地"阶段。它的"光明面"（零运维、自动弹性）是真实的，但它的"阴暗面"（冷启动、调试困难、厂商锁定）也是真实的。做一个"务实的Serverless用户"，而不是"狂热的Serverless信徒"。