cgo_enabled=0是serverless下go编译的硬性前提，否则因平台容器缺失glibc导致启动失败；必须配合goos=linux、goarch=amd64（或arm64）、-ldflags="-s -w"构建静态二进制，并延迟初始化、精简依赖与符号。
CGO_ENABLED=0 不是可选项，是硬性前提
没加 CGO_ENABLED=0 的 Go 二进制在 Serverless 平台上大概率直接失败，报错类似 standard_init_linux.go:228: exec user process caused: no such file or directory。这不是配置漏了，而是平台容器（alpine 或 distroless）压根没装 glibc，而默认开启 CGO 的 Go 会静态链接部分、动态链接 libc —— 一启动就找不到符号。
必须显式设环境变量再构建：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o main main.go- 别信本地 macOS/Windows 上
go build默认输出能跑通——host 和 target 混淆是常见坑 - ARM64 架构（如 AWS Graviton）要换
GOARCH=arm64，且确认平台 runtime 支持
go mod tidy 清不掉冷启动里的“幽灵依赖”
go mod tidy 只清理模块树里未被 import 的 module，但不影响最终二进制体积。真正拖慢冷启动的是那些被间接引入、却从未调用的代码段：比如 github.com/aws/aws-sdk-go-v2/config 默认启用 IMDS 探测逻辑，哪怕你只用 S3 客户端，也会把 HTTP client、JSON 解析器、TLS 初始化全链进来。
实操建议：
- 用
go tool nm -size -sort size ./main | head -15查看体积占比最大的 symbol，常暴露冗余的embed文件或未裁剪的 codec - 避免全局 import
github.com/aws/aws-lambda-go/events，改用子包如events/apigatewayv2 - 删掉所有测试相关 import，包括
_ "net/http/pprof"—— 它 embed 了整套前端资源，多出 1–2MB
init() 和包级变量初始化全算冷启动时间
很多人以为只有 lambda.Start() 之后才开始计时，其实从二进制 mmap 完成、到 main() 函数第一行执行前，所有 init() 和包级变量赋值都计入冷启动窗口。比如 var cfg = loadConfigFromS3() 这种写法，会在加载阶段就发起 HTTP 请求。
正确做法是延迟到 handler 内首次触发：
- 用
sync.Once控制 DB 连接、HTTP client、配置加载等单例初始化时机 - 把
init()里日志、指标、校验逻辑精简到最低限度，或改为异步上报 - 禁止在
main()里调用http.ListenAndServe或启动 goroutine 轮询——Serverless 不需要监听端口，纯属无效阻塞
vendor 目录对 Serverless 冷启动毫无帮助
go mod vendor 是为离线构建准备的，它把源码复制进项目，但 Go 构建过程仍按需链接符号。Serverless 场景下，vendor 不影响二进制体积、不减少 runtime 初始化开销、也不规避 CGO 问题——它只是让 go build 不去拉远程 module，仅此而已。
真正起作用的是构建参数和代码组织方式：
- 坚持
-ldflags="-s -w"去符号表，通常减小 30%–50% 体积 - 用
build tags隔离非生产代码（如本地调试用的 pprof、expvar） - 替换重型 SDK：比如用轻量 HTTP client 替代
aws-sdk-go-v2全量包，或直接发 raw HTTP 请求
冷启动优化不是靠“删掉几个 module”，而是控制符号链接边界、推迟运行时副作用、压缩加载镜像大小——这三个层面缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
