冷启动时长主要卡在go runtime初始化和main函数执行前；应避免main中i/o操作，用sync.once懒加载单例资源，精简lambda.start前逻辑，减小二进制体积。
冷启动时长主要卡在 Go runtime 初始化和 main 函数执行前
Go 编译成静态二进制，本身启动快，但 AWS Lambda 的 Go 运行时（aws-lambda-go）会在 handler 调用前做初始化：加载上下文、解析事件、注册回调。如果 main 里做了重操作（比如读大配置、连数据库、初始化复杂结构），就会拖慢首次调用。
- 避免在
func main()中执行 I/O 或同步阻塞操作；把初始化逻辑移到 handler 内部的懒加载或init()函数中（注意init()仍属冷启动阶段） - 用
sync.Once控制单例资源（如 HTTP client、DB 连接池）只初始化一次，且延迟到第一次请求时再触发 - 检查是否无意中在全局变量初始化时触发了耗时行为，例如：
var cfg = loadConfigFromS3()—— 这会直接进冷启动路径
lambda.Start 前的代码都算冷启动耗时
很多人以为只要 handler 里快就行，其实从二进制加载完成、到 lambda.Start 被调用之间的所有 Go 代码，全在冷启动窗口里。AWS 计费和超时都从这里开始算。
- 把日志初始化、指标注册、环境校验等逻辑尽量精简，或改用异步/延迟方式（比如首次请求时才上报 warmup 指标）
- 不要在
main里调用http.ListenAndServe或启动 goroutine 做轮询 —— Lambda 不需要监听端口，这些不仅无用，还会延长冷启动并可能触发超时 - 如果用了
github.com/aws/aws-lambda-go/events，确保只 import 实际用到的子包（如events/apigw），避免间接引入大量未使用的 JSON 解析逻辑
二进制大小直接影响冷启动加载时间
Lambda 加载函数代码是按 ZIP 包解压 + 二进制 mmap 的方式，体积越大，从 EFS 加载、验证签名、映射内存的时间越长。Go 默认编译出的二进制常含调试信息和反射符号，很容易超 10MB。
- 构建时加
-ldflags="-s -w"：去掉符号表和调试信息，通常能减小 30%–50% 体积 - 用
UPX压缩需谨慎 —— AWS 不禁止，但会增加解压 CPU 开销，实测对小函数（ - 检查是否误引了
net/http/pprof、expvar或测试相关包（如testing），它们会悄悄增大二进制
预置并发不是万能的，但必须配合 Go 的初始化模式
开了预置并发后，Lambda 会保持指定数量的执行环境常驻，但 Go 函数一旦被回收（空闲超 10 分钟），下次唤醒仍是冷启动 —— 和你本地 go run 启动一样，该走的初始化流程一步不少。
立即学习“go语言免费学习笔记（深入）”；
- 预置并发只保“容器”，不保“Go runtime 状态”；所以
init()和全局变量初始化仍会在每个新容器首次调用时执行 - 真正有效的是在 handler 里做轻量级 warmup：比如收到
isWarmUp: true的事件时，提前触发一次 DB ping 或 cache 预热，但别阻塞主请求流 - 别依赖
context.Deadline判断是否冷启动 —— 它反映的是本次请求剩余时间，不是环境生命周期状态
main 里所有非必要动作，让第一个请求尽可能轻；然后靠预置并发把“砍完之后”的那个轻量级启动，变成几乎感知不到的延迟。实际压测时，经常发现最拖时间的不是业务逻辑，而是某行没注释掉的 log.Printf("loading %v", heavyYAML)。 
