Go是构建Serverless函数的优选语言，但需适配各平台入口签名、静态编译、外部初始化、结构化日志及上下文超时控制。
Go 语言本身不直接提供“Serverless 运行时”，但它是构建 Serverless 函数的极佳选择——编译快、二进制小、内存占用低、启动迅速。真正决定是否“Serverless”的，是部署平台（如 AWS Lambda、Google Cloud Functions、Vercel、Cloudflare Workers）对 Go 的支持方式，以及你如何组织代码适配其生命周期模型。
Go 函数必须符合平台定义的入口签名
不同平台对 Go 入口函数的要求差异很大，写错 signature 会导致冷启动失败或 502 错误。关键不是“写个 main()”，而是实现平台约定的 handler 接口。
- AWS Lambda：使用
github.com/aws/aws-lambda-go/lambda，handler 必须是func(context.Context, events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error)或类似结构体类型 - Google Cloud Functions：用
cloud.google.com/go/functions/metadata+ HTTP handler 形式，函数签名为func(http.ResponseWriter, *http.Request) - Cloudflare Workers：不原生支持 Go，需通过
wrangler+workers-go编译为 Wasm，入口是main()中注册http.HandlerFunc - Vercel：要求导出一个默认的
handler变量，类型为func(http.ResponseWriter, *http.Request)，且文件名必须为api/[name]/index.go
避免在 handler 外部做耗时初始化（但可复用连接）
Serverless 平台会复用运行实例（warm container），但不保证每次调用都进入同一实例。把 DB 连接、HTTP 客户端、配置加载放在 handler 外部是安全且推荐的；但阻塞式初始化（如等待 Redis 连接超时、同步读大文件）会拖慢冷启动。
- ✅ 正确：在包级变量中初始化
redis.Client或&http.Client{Timeout: 10 * time.Second} - ❌ 错误：在
init()中调用http.Get("https://slow-api.example.com/health") - ⚠️ 注意：若使用
sql.Open，记得调用db.SetMaxOpenConns(10)和db.SetConnMaxLifetime，避免连接泄漏或过期失效
构建产物必须是静态链接的单二进制文件
绝大多数 Serverless 平台只接受单个可执行文件或 ZIP 包（含二进制+依赖），不提供 Go 环境或 go run。必须用 CGO_ENABLED=0 go build 静态编译，否则部署后报 “no such file or directory”（找不到 libc）。
立即学习“go语言免费学习笔记（深入）”；
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o bootstrap main.go
其中 GOOS=linux 是必须的（Lambda / Cloud Functions 底层是 Linux 容器），-a 强制重编译所有依赖，-ldflags 确保完全静态链接。生成的 bootstrap 文件就是最终上传物（Lambda 要求文件名必须为 bootstrap）。
日志与错误不能只靠 fmt.Println
Serverless 平台通过标准输出/错误流捕获日志，但格式和上下文有要求。直接 fmt.Println 会丢失请求 ID、时间戳、结构化字段，也难以对接云监控系统。
- AWS Lambda：用
log.Printf或结构化日志库（如github.com/aws/aws-lambda-go/log），它自动注入 request ID - Google Cloud Functions：用
log.Print或log.Printf，GCP 自动识别并打上 trace ID - 自定义日志：避免拼接字符串，改用
zap或zerolog输出 JSON，并确保os.Stdout未被重定向或缓冲（加log.SetOutput(os.Stdout)+log.SetFlags(0)） - 错误处理：不要忽略
err，返回给 handler 的error会被平台记录为失败事件；HTTP handler 则应设置w.WriteHeader(500)并写明错误原因
最易被忽略的是冷启动时的上下文超时——比如在 handler 内部首次调用外部 API，而没设 timeout，可能卡住整个函数执行周期。务必给所有 I/O 操作显式设置 context.WithTimeout，并把传入的 ctx 向下透传到底层调用。
