延迟加载在Go中必须用于数据库连接池、配置中心命名空间、第三方SDK客户端、大文件解析及缓存预热等场景，以避免启动阻塞、内存浪费和单点故障拖垮进程。
延迟加载在 Go 中不是“要不要用”的问题，而是“哪些地方必须用”的问题——它直接决定服务能否扛住启动洪峰、内存是否被冗余配置吃光、以及某些模块故障会不会拖垮整个进程。
数据库连接池初始化太早会卡住启动
很多项目把 sql.Open 放在 init() 或 main() 开头，结果一启动就尝试连 DB。一旦数据库没就绪、网络不通或认证失败，整个服务起不来。
- 真实场景：K8s Pod 启动时 DB 还在拉镜像，
init()里连不上就 CrashLoopBackOff - 正确做法：用
sync.Once包一层，首次调用GetDB()时才真正拨号 - 注意点：别只检查
err != nil，还要db.Ping()，否则拿到的是个“假连接”
配置中心多命名空间不该全量加载
Agollo 支持逗号分隔多个命名空间（如 "application,database,redis"），但默认行为是启动时全量拉取——而你的订单服务根本用不到 payment 命名空间的配置。
- 典型浪费：一个微服务加载 8 个命名空间，实际只用其中 2 个，内存多占 30%+，启动慢 400ms
- 解决方案：初始化时只传
"application"，其他命名空间用client.GetConfigAndInit("redis")按需触发 - 坑点：
GetConfigAndInit是异步拉取，如果立刻读Get("redis.timeout")可能返回空，得加WaitForLoad或兜底默认值
第三方 SDK 客户端初始化耗时且非必需
比如阿里云 OSS、腾讯云 COS、或是内部封装的风控 SDK，它们的 NewClient() 往往包含鉴权、endpoint 解析、连接池预热等动作，但你可能只在上传头像时才用到 OSS。
- 错误模式：全局变量
var ossClient = oss.NewClient(...)—— 启动即阻塞 - 推荐结构：定义接口
type OSS interface { PutObject(...) }，proxy 结构体里字段为*oss.Client（初始 nil），首次调用时once.Do(init) - 关键细节：
init函数里别做同步 HTTP 请求，否则并发调用PutObject会被集体卡住；超时必须设，比如context.WithTimeout(ctx, 5*time.Second)
大文件解析或缓存预热不能放在启动阶段
有些服务要加载本地规则文件（如 JSON/YAML 格式的风控策略）、或从 Redis 扫描上万 key 预热本地 LRU 缓存——这些操作耗时几百毫秒到几秒，不应阻塞 HTTP server 监听。
- 表现症状：
http.ListenAndServe卡住，/healthz 返回 503，K8s readiness probe 失败 - 实操建议：用 goroutine 异步加载，但必须配
sync.WaitGroup或 channel 通知主线程“已就绪”，避免请求进来时缓存还是空的 - 容易忽略：异步加载失败时，要记录 error 并允许后续重试（比如定时每 5 分钟再试一次），而不是静默失败
延迟加载真正的难点不在“怎么写”，而在“判断哪里该延”。最常被误判的是日志实例、指标收集器、中间件注册——它们看似轻量，但在高并发压测下，初始化过程中的锁竞争或反射调用反而成为瓶颈。上线前务必用 go tool trace 看一眼启动阶段的 goroutine 阻塞点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
