原来 serverless framework 只是一个开发者工具啊

aws 的话直接用 cdk ，不光可以部署 lamba 还能同时用代码管理 aws 上的各种资源。至于 aws 的那个 sam 我的建议是不要去碰，否则会变得不幸。想本地跑 lambda 的话直接随便找个网络框架然后写个兼容层是调用 lambda 代码是最简单的

@witcat 看你 lambda 是拿来干嘛的。
如果是做后端，一遍是 lambda+apigatetway 。本地兼容层的意思就是找个 http 框架（比如 golang 的 gin ，typescript 的 nestjs 之类的），然后写个转换函数或类，把 http 框架的 request 对象转换成 lambda 用的 event 对象，然后把 lambda 的 response 对象(或 callback 函数)转成框架用 response 对象。相当于自己整了个 apigateway 。这样你就能在本地像普通 http 服务器那样通过请求 api 调用 lambda 做测试了。转换的逻辑我是写到了框架的 controller 里，可以根据你的喜好来选。
不过有点要注意的是，lambda 的模型是每个请求都开一个新的容器，每个容器同时只处理一个 http 请求（有点类似 php ），不同请求之间是彻底隔离的。用了本地的兼容层的话，需要注意别用本地服务器做多线程请求，否则行为会和实际的 lambda 不一样

如果是拿 lambda 做小脚本之类的话，那就不用什么兼容层了，直接调用就行

@BeautifulSoap #3 谢谢 明白了

@BeautifulSoap 你们 lambda 的场景是什么呢，感觉单一职责的函数，写起来还不如放一起呢，同一资源的 crud 要写 4 个函数，打包 4 次

@mkb lambda 基本普通 api 服务器都可以用啊。
lambda 可以单一职责，也可以像普通框架开发那样一个函数处理所有 api ，一些框架都有对应的 serverless 版本，或者你高兴的话自己写一个 event 转换层也行。

一个 api 一个函数虽然函数多，但部署打包其实也没那么麻烦，建议上 aws cdk 部署 lambda ，这样部署起来非常轻松。cdk 里指定好对应函数代码入口后就是完全自动打包部署的

至于选择单一职责函数还是多职责函数，各有优缺点。单一职责函数后期运维的时候每个 api 都是彻底分开的，调查日志的时候极其轻松（不用在一堆 api 的日志里找对应 api 了），配合 apigateway 的话还可以精准统计每个 api 的请求负载，处理时间，错误率之类的。缺点就是 lambda 的冷启动问题，如果你 api 每天都请求数是稀疏的，那么每个函数都会遇到冷启动问题，反映到用户端就是 api 反应缓慢（当然 这个问题加钱就可以解决）

多职责函数的话就没有上面说的单一职责函数的优点了，好处就是冷启动问题会大为缓解
具体怎么选择看你自己

@BeautifulSoap 函数之间的调用，每次都要花钱的吧，一个请求调用 n 个后端函数，就要花 n 次钱