延迟加载不是简单推迟所有初始化，而是分层错峰：日志、信号监听等必须立即初始化；DB连接池等可异步预热；pprof等低频组件才严格按需加载。
延迟加载不是“把所有初始化都拖到第一次请求”
很多人误以为延迟加载就是把 DB 连接、配置解析、指标上报全塞进 sync.Once，等第一个 HTTP 请求进来才执行。结果首请求 P95 延迟飙到 800ms，用户感知是“服务启动了但卡得不行”。这不是启动快，是把延迟从启动阶段平移给了用户。
真正有效的延迟加载，核心是分层错峰：哪些必须在 main() 返回前就位（如日志、信号监听），哪些可以放到第一个请求前（如路由注册、中间件链构建），哪些真能等到首次调用（如某个 admin 接口专用的缓存 client）。
- 必须立即初始化的：日志实例、
http.Server结构体、信号 channel、健康检查 endpoint 的 handler - 可提前异步加载的：数据库连接池（用
db.PingContext()验证后才标记 ready）、OpenTelemetry exporter（启动 goroutine 后台建连，不阻塞 main） - 严格按需的：debug 接口用的 pprof handler、低频管理命令的 CLI parser、某个特定业务模块的 SDK client（如只在 /v1/batch/export 路径下用到的 S3 client）
全局变量 + init 是冷启动内存峰值的最大推手
Go 启动时会按导入顺序执行所有包的 init() 函数，并完成所有全局变量初始化。只要一个第三方包在 init() 里做了 make([]byte, 0, 10*1024*1024) 或 new 了 1000 个 struct，这部分内存就在进程启动瞬间被锁定——哪怕你整个生命周期都不会调用它。
典型高危模式：
立即学习“go语言免费学习笔记（深入）”；
-
var mux = http.NewServeMux()—— 底层 map 在 init 阶段就分配 bucket 数组 -
var tracer = otel.Tracer("myapp")—— OpenTelemetry 默认预建大量内部结构体 -
var cache = bigcache.NewBigCache(...)—— 初始化即分配大块内存池
解决办法很直接：全干掉。改成函数返回值或结构体字段，靠闭包/依赖注入传入，或用 sync.Once 包裹（但别在 init() 里调它）。
slice/map 的 cap 预设是隐形内存黑洞
写 make([]string, 0, 1024) 看似稳妥，但如果这个 slice 整个生命周期最多只存 3 个元素，那 1024 个指针的底层数组就白占着。Go 不会在运行时缩容，GC 也不会回收——只要变量还活着，底层数组就得留着。
高频路径可预估 P99 长度设 cap，但必须查真实监控数据，不是拍脑袋填 1024；低频路径（比如 admin 接口用的错误日志聚合列表）直接用 make([]T, 0)，让第一次 append 触发真实扩容。
map 同理：make(map[string]int, 0) 在 Go 1.21+ 有优化，空 map 不分配 bucket 数组；而 make(map[string]int, 64) 一上来就分配 64 个 bucket 槽位，哪怕你只存 1 个 key。
第三方 SDK 的 AutoInit 往往默认开满
AWS SDK、Datadog tracer、GCP client、甚至某些 ORM，都在包级 init() 或全局变量初始化时悄悄预建资源。比如 AWS SDK v2 默认启用 config resolver、credentials chain、HTTP client pool，全在启动时分配。
查文档找这类配置项：
- AWS SDK: 使用
config.WithDefaultRegion("")+ 显式传config，避免config.LoadDefaultConfig() - OpenTelemetry: 用
otel.WithNoDefaultTracerProvider()和otel.WithNoDefaultMeterProvider() - PostgreSQL driver: 不用
sql.Open("postgres", ...)全局变量，改用 factory 函数 + 连接池复用
没提供开关？那就 fork 或 patch，或者换更轻量的替代实现——比如用 pgxpool 替代 database/sql + pq。
最常被忽略的一点：延迟加载本身不解决内存归还问题。即使你把所有东西都懒加载了，如果某次初始化分配了 50MB 内存又很快释放，Go runtime 可能不会立刻把这部分内存还给 OS（尤其在容器里），导致 RSS 居高不下。这时候得结合 GOMEMLIMIT 和观察 HeapIdle 指标来判断是否需要干预，而不是盲目加 runtime.GC()。
