延迟加载必须用 sync.Once 或 sync.Lazy 控制执行时机：init() 或 main() 中禁止 I/O 操作，Agollo 需禁用自动同步并手动按需加载，镜像构建须精简依赖，K8s 探针需与初始化解耦。
延迟加载必须用 sync.Once 或 sync.Lazy 控制执行时机
Go 服务启动慢，八成是因为在 init() 或 main() 开头就干了不该干的事：连数据库、读大配置、启 goroutine、解析 YAML。这些操作不延迟，冷启动时全卡在主线程里。
正确做法是把初始化逻辑包进闭包，交给 sync.Once 或 Go 1.21+ 的 sync.Lazy 管理：
-
sync.Once适合已有代码改造，只需加一层包装，线程安全且无额外依赖 -
sync.Lazy更简洁，值语义自动触发，但要求 Go ≥ 1.21，且不能用于指针或接口字段直接赋值（需显式调用.Load()） - 避免在
init()中调用任何含 I/O 或网络的函数——哪怕只是os.Getenv()后立刻http.Get()，也会让整个包初始化阻塞
Agollo 配置延迟加载要禁用自动同步，改用 GetConfigCache()
Agollo 默认初始化时会拉取全部命名空间（如 "application,database,redis"），这在容器刚启动、网络未就绪时极易超时失败或拖慢启动。关键不是“能不能配多命名空间”，而是“什么时候真正去拉”。
必须关闭自动加载，手动按需触发：
立即学习“go语言免费学习笔记（深入）”；
- 初始化 client 时设
IsBackupConfig: false并跳过Start()，防止后台 goroutine 自动同步 - 首次需要某配置时，显式调用
client.GetConfigCache("database")，它内部已用sync.Once保证只拉一次 - 不要在
init()里调GetConfigAndInit()—— 这个方法本质就是“立即同步”，和延迟加载背道而驰
容器镜像构建阶段就要为延迟加载留出余地
延迟加载不是 runtime 技巧，它和构建方式强耦合。如果 Dockerfile 里还用 ubuntu:22.04 + apt install curl，或者忘了关 CGO_ENABLED，那再好的懒加载也白搭。
实操上必须做到：
- 基础镜像用
gcr.io/distroless/static:nonroot或alpine:latest，确保无 libc 依赖，避免运行时因动态链接失败导致预热逻辑 panic - 编译命令加
-ldflags="-s -w"，减小二进制体积 → 减少 mmap 加载时间 → 让第一次GetDB()调用更快返回 -
CGO_ENABLED=0必须设置，否则net包可能 fallback 到 cgo resolver，在容器 DNS 未 ready 时卡住整个初始化流程 - 多阶段构建中，运行阶段只 COPY 二进制，别带
go.mod或源码——这些文件会干扰某些配置库（如 viper）的自动发现逻辑，意外触发非预期加载
Kubernetes 探针配置不当会让延迟加载失效
很多团队以为“我把 DB 连接延迟到第一次 HTTP 请求再建，探针就该配得宽松点”，结果 readinessProbe 检查 /healthz 时，handler 内部却偷偷调了 GetDB().Ping() —— 这等于把延迟加载又变回了启动时加载。
健康检查必须和延迟加载解耦：
- readinessProbe 的 handler 只读内存状态，比如用
atomic.Bool标记 “DB 已连通”，由真实 DB 初始化成功后置为 true - livenessProbe 用
exec cat /tmp/healthy这类纯文件检查，完全绕过业务逻辑 - startupProbe 必须启用，initialDelaySeconds 设为略大于最长预热时间（例如 DB Ping + Redis Auth 共需 2.8s，则设 4s），否则 kubelet 在预热完成前就把 Pod kill 了
延迟加载真正的难点不在代码怎么写，而在所有环节是否对齐：构建时不埋雷、运行时不越界、编排时不误判。任何一个环节把“懒”当成“不管”，都会让优化归零。
