Go语言延迟加载是将非必要初始化推迟到首次使用时执行，以提升冷启动性能；init()函数串行阻塞、第三方库隐式初始化、全局变量预分配等是冷启动瓶颈；sync.Lazy比sync.Once更安全轻量；日志配置、监听地址、信号处理等关键路径不可懒加载；容器预热须在main中ListenAndServe前完成。
Go语言延迟加载不是“让初始化变慢”，而是把不必要立刻执行的初始化，挪到真正需要时再做——这对冷启动性能提升最直接有效。
为什么init()是冷启动第一瓶颈
Go程序在main()执行前，会同步、串行地运行所有包的init()函数。一旦某个init()里做了数据库连接、配置远程拉取、SDK自动注册或大结构体预分配，整个进程就卡住不动，直到它完成。
- 第三方库（如
spf13/viper、aws-sdk-go）常在init()里注册默认行为或初始化全局客户端 - 全局变量声明时直接调用构造函数（如
var db = NewDB(...)），等价于隐式init() - 哪怕只是
make([]byte, 0, 64*1024)，也会立即分配 64KB 底层数组，且冷启动后长期不释放
sync.Lazy比sync.Once更适合延迟加载
Go 1.21+ 引入的sync.Lazy是值语义的延迟初始化类型，比手写sync.Once更安全、更轻量，且天然避免误在init()中调用它。
-
sync.Once需配合指针/全局变量使用，容易因并发访问或提前触发而失效 -
sync.Lazy可直接嵌入结构体字段，首次读取时才执行工厂函数，且无锁路径快 - 错误示范：
var cfg *Config; func init() { cfg = loadConfig() }→ 冷启动必执行 - 正确写法：
cfg sync.Lazy[Config]，然后cfg.Load().DBURL首次访问才初始化
哪些东西绝对不能懒加载
延迟加载不是“全盘懒化”，关键路径必须前置保障。否则冷启动虽快，首请求却卡死。
- 日志配置（
zerolog/zap全局logger）、信号处理、进程退出钩子必须在main()早期完成 - HTTP服务监听地址、TLS证书路径这类启动依赖项，不能等到第一个请求才读文件
- 若用了
http.ServeMux或gin.Engine全局实例，其底层map和slice分配已发生；应改为局部变量 + 闭包传入 handler - 第三方 SDK 的 auto-init 行为（如 OpenTelemetry 的
otel.Tracer全局单例）务必查文档关掉，改用显式sync.Lazy封装
容器环境要预热，但别在init里做
Kubernetes 或 Serverless 环境下，冷启动后立即接受流量，但 DB 连接池、gRPC 连接、TLS 会话缓存这些“首次开销”仍会落在第一个请求上——这不是懒加载的问题，是预热时机错了。
- 预热动作必须放在
main()函数中、http.ListenAndServe之前，且要超时控制（如ctx, _ := context.WithTimeout(context.Background(), 3*time.Second)） - 避免
db.Ping()阻塞：用db.PingContext(ctx)，失败也不 panic，只打 warn 日志 - 健康检查端点（如
/health/ready）应返回内存标记（atomic.Bool），而非实时查 DB —— 标记由预热成功后置为 true - 镜像构建阶段可提前读入证书、配置模板等静态资源到内存，避免运行时 IO
延迟加载真正的难点不在语法，而在判断“谁真需要马上活，谁可以睡着等叫醒”。一个sync.Lazy字段加得不对，可能把首请求延迟从 50ms 拉到 800ms；而一个本该预热的连接池没动，又会让冷启动优势白费。时机比技巧重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
