go函数冷启动延迟高因main/init中耗时初始化，应移至包级变量+sync.once；handler须无状态幂等；内存宜设128mb–512mb；所有i/o必须传入context.context。
Go 函数冷启动延迟高，main 里别做初始化
Lambda 每次冷启动都会重新执行 main 函数，如果在里面初始化数据库连接、读配置文件或加载大模型，延迟直接飙升到秒级。Go 的 init 函数也一样会被每次触发——它不因函数复用而跳过。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把耗时初始化（如
sql.Open、json.Unmarshal配置、http.Client构建）提到包级变量 +sync.Once控制，确保只在首次调用时执行 - 避免在
main中调用log.printf或任何阻塞 I/O；日志应交由 handler 内按需打 - 配置文件优先用环境变量（
os.Getenv），而非从/var/task/读取文件——后者触发 EFS 或磁盘访问，不可控
lambda.Start 的 handler 必须是无状态、幂等的
Lambda 可能复用同一实例处理多个请求，也可能在任意时刻回收实例。如果你在 handler 里改了全局变量、缓存了未加锁的 map、或依赖上一次调用留下的 time.Now() 副作用，结果会随机出错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- handler 函数签名必须是
func(context.Context, events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, Error)这类标准形式，不要试图传入自定义 Struct 实例 - 所有中间状态（如临时计算结果、用户 Token 解析值）必须存在 handler 局部变量里，别往包变量里塞
- 若需跨调用缓存（如 JWT key），用
sync.Map+ TTL 控制，别用普通map配mutex——竞态难测，且 Go 的sync.Map在低并发下性能反而更好
内存设太高反而拖慢 GC，128MB–512MB 是 Go 的甜点区间
很多人以为“内存越大越快”，但 Go runtime 的 GC 周期和堆大小强相关。Lambda 给 3GB 内存时，Go 可能迟迟不触发 GC，导致堆膨胀、后续调用卡顿；而设成 1024MB 后，冷启动时 runtime 要花更多时间扫描初始堆。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
aws lambda get-function-configuration --function-name xxx查当前内存设置，结合 CloudWatch 的Duration和MaxMemoryUsed指标反推：若长期MaxMemoryUsed ，就别设 <code>1024MB - 压测时固定超时为
30s，观察不同内存档位下的 P95 延迟曲线——Go 函数在256MB和384MB往往比512MB更稳 - 禁用
GOGC=off，也不要用debug.SetGCPercent手动调 GC 阈值；Lambda 的短生命周期不适合复杂 GC 策略
context.Context 超时没传进下游调用，会导致 Lambda 强制终止却无报错
Lambda 在超时前 100ms 会向进程发 SIGTERM，但 Go 默认不响应这个信号。如果你的 handler 里调了 http.NewRequestWithContext 却没把 ctx 传给 client.Do，或者用了 time.Sleep 硬等，函数会在静默中被杀，CloudWatch 只显示 “Task timed out”，查不到真实卡点。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有 I/O 操作必须显式传入
ctx：比如db.QueryRowContext(ctx, ...)、client.PostWithContext(ctx, ...) - 避免
time.After或time.Sleep，改用select { case - 在 handler 开头加
defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }()，至少捕获 panic 导致的提前退出
Go 在 Lambda 上真正难调的不是语法或部署，而是 runtime 行为和 serverless 生命周期的隐式耦合——比如 sync.Once 在 warm instance 上只生效一次，但你根本不知道这次调用复用了哪个实例的内存空间。