延迟加载不减少冷启动耗时，仅改善感知速度；必须早初始化日志、指标、路由、信号监听等无I/O无副作用操作，I/O类如DB/Redis连接、远程配置等须首请求时用sync.Once+超时控制延迟加载。
延迟加载本身不减少冷启动耗时，反而可能让冷启动“看起来更快”，但首请求变卡——关键在区分哪些该延、哪些必须早。
哪些初始化必须放在冷启动阶段
日志配置、指标注册器、HTTP 路由注册（如 http.HandleFunc）、信号监听（signal.Notify）这些不涉及 I/O 且无副作用的操作，必须在 main() 开头或 init() 中完成。它们是服务“就绪”的前提，延迟会导致首次请求无法打点、路由未注册或 panic 无法捕获。
常见错误：把 zap.NewProduction() 放进 sync.Once —— 它内部会预建 encoder、time encoder、调用栈解析器，这些结构体分配是纯内存操作，早做比晚做好；真要优化，换 zap.NewDevelopment() 或自定义轻量 EncoderConfig。
哪些初始化必须延迟到首请求
所有带 I/O 或依赖外部系统的操作，都该推迟到第一次 handler 调用时执行，用 sync.Once 或 Go 1.21+ 的 sync.Lazy 包裹：
立即学习“go语言免费学习笔记（深入）”；
-
database/sql.Open后的db.Ping()（连接池建立 + TLS 握手） redis.NewClient().Ping()-
viper.ReadInConfig()（读取远程配置中心或 S3） -
http.Client初始化中启用http.Transport的长连接池、TLS 配置等重逻辑
注意：sync.Once.Do() 内部不能含无 timeout 的阻塞调用。例如 db.Ping() 必须配 context.WithTimeout，否则所有并发首请求会排队等待一个失败的数据库连接。
全局变量初始化里的隐形陷阱
Go 编译器会在 main() 前执行所有包级变量初始化，这里极易埋雷：
-
var cfg = loadConfigFromS3()—— 直接进冷启动路径，AWS Lambda 计费从这行开始 -
var mux = http.NewServeMux()看似安全，但若后续在init()里注册了大量 handler，底层 map 可能被预分配大 cap -
var client = &http.Client{Transport: &http.Transport{...}}—— Transport 初始化会预建空闲连接池、TLS 状态机，占内存又不立即需要
解决办法：把这类变量声明为空指针或零值，用函数封装初始化逻辑，靠 sync.Once 触发；避免在 init() 里调 sync.Once.Do() —— init() 本就是单次同步执行，加 Once 是误导维护者且无意义。
延迟加载不是懒加载一切
把所有初始化都堆进第一个 HTTP 请求，会导致 P95 首请求延迟飙升。用户感知是“服务起来了，但第一次调用卡 800ms”，而不是“启动快”。必须分层：
- 「立刻可用」层：日志、metrics、路由、健康检查 endpoint —— 冷启动做完
- 「错峰加载」层：缓存预热、异步上报 warmup 指标、后台 goroutine 加载静态资源 —— 首请求后异步触发
- 「按需加载」层：DB 连接池、Redis 客户端、远程配置 —— 第一次业务调用时同步初始化（带超时）
最易被忽略的是：Lambda 的「冷启动窗口」从二进制 mmap 完成就开始计时，lambda.Start() 之前的所有 Go 代码都算进去。哪怕你只写了一行 fmt.Println("warmup")，它也在冷启动里。
