go选serverless框架应优先支持http.handlerfunc复用、避免强绑定网关，冷启动优化关键在延迟init操作、精简二进制，并根据云厂商直选aws-lambda-go而非过度抽象的gofaas。
Go 里怎么选 Serverless 框架：别被“云原生”带偏节奏
Go 写 Serverless 应用，核心就两条：能不能冷启动快、能不能少依赖。不是越“云原生”越好，而是越贴近 net/http 生态、越不改写你原有 HTTP handler 的框架越省心。
- 优先看是否支持直接复用
http.HandlerFunc—— 比如aws-lambda-go的lambda.StartHTTP就能零改造接入 Gin/Chi - 避开强绑定自研网关或中间件的框架（比如某些封装了完整事件总线、服务发现的“全栈 Serverless 框架”），Go 项目一旦上了这类框架，本地调试和单元测试成本陡增
-
serverless-framework+serverless-go插件看似通用，但实际打包时容易漏CGO_ENABLED=0，导致部署到 Lambda 报exec format error
冷启动卡在 300ms 以上？先查 init 阶段干了啥
Go 的冷启动延迟，90% 出在 init() 函数和全局变量初始化上，不是函数体执行慢。
- 把数据库连接、配置加载、日志实例化这些重操作，从
init()搬到 handler 第一次调用时的懒初始化逻辑里 - 避免在包级作用域做
http.DefaultClient = &http.Client{...}这类全局覆盖，它会在init时触发 TLS 初始化，拖慢首请求 - 用
go build -ldflags="-s -w"去掉调试符号，二进制小 20%，S3 下载和解压更快
aws-lambda-go 和 gofaas 的真实差异在哪
不是“功能多寡”，而是事件模型抽象层级不同：前者让你直面 AWS Event 结构，后者试图统一事件源但增加了转换开销。
-
aws-lambda-go的events.APIGatewayV2HTTPRequest是裸结构体，字段名和 API Gateway v2 的 JSON 字段一一对应，调试时打日志一眼能对上；gofaas的Request是泛型包装，要查文档才能确认.Body是原始字节还是已解码的 map -
gofaas默认启用上下文透传（比如 X-Request-ID 自动塞进context.Context），听着好，但会干扰你自己的 middleware 链，尤其用了chi或gorilla/mux时容易重复解析 header - 如果你只跑 AWS，别为了“可移植性”选
gofaas—— 它目前对 GCP Cloud Functions 的适配是靠模拟 Lambda runtime API，实测超时率高 3 倍
本地调试时 context.DeadlineExceeded 频发？检查你的 timeout 设置链
Serverless 环境的 timeout 是硬限制，但 Go 的 context.WithTimeout 如果套在 handler 外层，会和平台 timeout 叠加出不可预测行为。
立即学习“go语言免费学习笔记（深入）”；
- AWS Lambda 的函数 timeout 是从 runtime 接收请求开始计时，不是从你的
http.Serve开始 —— 所以别在main()里用context.WithTimeout(context.Background(), 30*time.Second)包整个 handler - 正确做法：在 handler 内部按业务分段设子 context，比如 DB 查询用
context.WithTimeout(r.Context(), 5*time.Second)，外部 HTTP 调用用10*time.Second - 本地用
lambda.Start测试时，Lambda runtime 模拟器不会强制中断 goroutine，所以DeadlineExceeded不会触发 —— 必须用lambda.StartWithOptions显式传入lambda.WithTimeout(10)才能复现
最常被忽略的一点：Go 的 http.Server 在 Serverless 场景下根本没机会用上 ReadTimeout 或 IdleTimeout，这些设置在 Lambda 里完全无效。真正起作用的只有平台层 timeout 和你代码里手动控制的 context。
