大家好，我是刘布斯。

技术圈虽然不像前些年，隔三差五就冒出个新词刷屏，但确实也是有些新东西，比如今天要谈到的 “Serverless”。

第一次听到 “Serverless”这个词的时候，第一反应跟很多前端兄弟一样，心里咯噔一下：“没服务器？那我们写的网页、App 跑哪儿去？后端大哥们是不是要下岗了？”

后来研究了一阵，也在几个项目里实实在在地用了起来，才发现压根不是那么回事。Serverless 不是真的“没有服务器”，而是“无需再关心服务器了”。

打个比方。以前做项目，就像是自己开个餐馆。得操心租店面、装修、买灶具、请厨师、请服务员（对应着买服务器、配环境、装软件、写后端应用、做运维）。

现在 Serverless 来了，它更像是加入了“美团外卖”平台。开发者只需要写好“菜单”（也就是核心业务代码，一个“函数”），然后在平台上注册。有客人点餐（触发事件），平台就会自动找一个空闲的厨房和厨师（计算资源），把菜炒好送出去。忙的时候，平台会自动多找几个厨房；闲的时候，厨房就关灯休息。开发者只需要按订单量付给平台抽成，完全不用管厨房在哪、厨师累不累、水电煤气费多少。

今天，我就想用大白话，聊聊 Serverless 到底是是什么，以及它怎么就成了我们前端开发者的一个“超级外挂”。

Serverless，赋能前端工程师

说实话，Serverless 对我们前端的赋能，可能比对后端还要大。

为啥？

因为它极大地降低了实现一个完整业务闭环的门槛。

在没有 Serverless 的时代，我们前端的边界非常清晰：把 UI 写好，把交互做了，调后端给的 API，把数据展示出来。没错，这就完事了。

但总有些时候，会让人觉得很“憋屈”：

• “我就想做个简单的官网，用户能提交个表单，把信息发到我邮箱里。就这么个小功能，还得麻烦后端大佬起个服务，配个 Nginx，搞半天？”
• “UI 需要的数据，要从 A、B、C 三个微服务里分别取，然后在前端聚合。为啥不能有个中间层，直接给我一个清爽的接口？”
• “这个项目就一个活动页，可能就上线一周，为了这一周的流量，要去申请一台服务器，走半个月的流程？”

这些不大不小、后端又没空搭理的“灰色地带”，就是 Serverless 大显身手的地方。它让我们前端，第一次可以只用我们最熟悉的 JavaScript (或者 TypeScript)，写上几十行代码，就能轻松搞定一个以往需要完整后端链路才能实现的功能。

这种感觉，就像是以前只能造车轮，现在突然有了一个引擎和底盘，能自己组装出一台可以跑的车。

哪些场景适合 Serverless ？

理论说再多不如上场景。这里列几个 Serverless 用得最舒服的地方，马上就能 get 到它的妙处。

1. 静态网站的“动态心脏” (BFF 层)

   这是最最经典的用法。现在很多网站都用 Next.js / Nuxt.js / Gatsby 这类框架开发，部署成静态页面，访问速度飞快。但纯静态满足不了所有需求。比如一个“联系我们”的表单提交、一个用户评论功能、一个简单的 Stripe 支付回调。

   这时候，可以直接在项目里（比如 Next.js 的 pages/api 目录下）创建一个 submit-form.js 文件，写一个函数，export 出去。部署的时候，Vercel 或者 Netlify 这类平台会自动把它变成一个 Serverless Function，生成一个 API 地址。

   前端直接调这个 API 就行了。整个过程，开发者甚至都没离开前端项目代码库，体验极其丝滑。这个函数，就成了 BFF (Backend for Frontend) 层，专门为前端应用提供量身定制的服务。

2. “召之即来，挥之即去”的工具函数

   项目里经常有些“一次性”或者“低频”的处理任务。比如用户上传了一张图片，需要把它压缩、裁剪成不同尺寸的缩略图。

   搁以前，这事儿得后端写个接口，前端把图片传过去，后端处理完再返回 URL。现在呢？可以把图片直接传到阿里云 OSS 或者亚马逊 S3 这种对象存储服务。然后设置一个触发器：一旦这个存储桶里有新图片上传，就自动触发一个 Serverless 函数。这个函数会拿到图片，用 sharp.js 这类库处理完，再存回存储桶。

   全程自动化，而且只有在上传图片那一刻才消耗计算资源，费用几乎可以忽略不计。其他像发送邮件、生成 PDF 报告、跑个定时小脚本（Cron Job），都是绝佳场景。

3. 胶水层与 API 代理

   有时候，需要调用的第三方 API 有跨域问题，或者需要一个固定的 IP 出口，再或者不希望在前端暴露 API Key。写个 Serverless 函数做一层代理转发，简直完美。前端请求这个函数，函数在“服务端”去请求真正的第三方 API，再把结果返回给前端。安全、干净、利索。

雷区警告

Serverless 不是万能药，它也有它的脾气。硬拿它干不擅长的事，那绝对是给自己挖坑。

1. 需要长时间运行的任务

   Serverless 函数的生命周期通常都很短，大部分平台都限制在几秒到几分钟不等。如果想用它来跑一个需要半小时的视频转码任务，或者一个复杂的数据分析脚本，那它跑到一半就会被平台“掐死”。

2. 极低延迟的实时应用

   Serverless 有个著名的 “冷启动” (Cold Start) 问题。如果一个函数很久没被调用，它会进入“休眠”状态。下一次被调用时，平台需要重新初始化它的运行环境，这个过程可能会多花几百毫SH甚至更长的时间。对于一个普通的 API 请求，用户几乎无感。但如果是做一个需要毫秒级响应的实时对战游戏服务器，或者高频交易系统，那这个延迟是致命的。

3. 复杂的、有状态的服务

   Serverless 函数天生是“无状态”的。每次调用，都是一个全新的环境。不能指望它记住上次调用的结果。如果要构建一个需要管理大量长连接（比如 WebSocket 聊天室）或者需要复杂事务处理的系统，传统的服务器应用或者专门的状态管理服务才是更好的选择。

总的来说，我的看法是：Serverless 不会取代传统后端，但它会成为现代前端工程师的标配技能之一。

它就像是工具箱里的一把瑞士军刀，虽然不能当主战武器去劈山，但处理那些零零碎碎、需要快速响应的“小活”，简直不要太顺手。

所以，别再把它当成一个遥远又可怕的概念了。现在不少平台都提供了一些免费额度，大家完全可以搭建一个自己的项目，尝试写下第一个 Serverless Function。当成功地在浏览器里调通自己写的第一个“后端接口”时，就会明白我说的“外挂”到底是什么感觉了。

这个行业就是这样，永远有新东西出来。与其焦虑，不如动手玩玩看。

最后

还没有使用过我们刷题网站（https://fe.ecool.fun/）或者刷题小程序的同学，如果近期准备或者正在找工作，值得看一看，题库已经录入 1600 多道前端面试题，除了八股文，还有现在面试官青睐的场景题，甚至最热的AI与前端相关的面试题已经更新，努力做全网最全最新的前端刷题网站。

有会员购买、辅导咨询的需求，可以通过下面的二维码，联系我们的小助手。