首次访问变慢是因将无超时I/O操作（如db.Ping、viper.ReadInConfig）塞入sync.Once的同步执行流，导致首请求阻塞；正确做法是用context.WithTimeout并发初始化并复用资源。
首次访问变慢是因为延迟加载把阻塞操作从启动时挪到了请求路径上
延迟加载本身不慢，慢的是你把本该异步/预热的 I/O 操作（比如 db.Ping()、viper.ReadInConfig()、http.Get()）塞进了首次请求的同步执行流里。Go 的 sync.Once 保证只执行一次，但不保证“不卡住”——如果里面是没设 timeout 的数据库连通性检查，那第一个 HTTP 请求就会干等几秒。
常见错误现象：
-
go run main.go启动快，但首请求耗时 1.2s；go build后运行也一样 -
pprof显示热点在runtime.netpoll或os.ReadFile，而非业务逻辑 - 用
curl -w "@format.txt" http://localhost:8080/health"测 TTFB，发现只有第一个请求慢，后续稳定在 5ms
sync.Once.Do 里不能放无超时的阻塞调用
很多人以为 sync.Once 是“安全懒加载”的银弹，却忘了它只是串行锁，不是异步调度器。一旦 Do 里的函数卡住，所有并发的首请求都会排队等它完成——这不是并发变串行，是直接阻塞整个请求队列。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
- 所有带 I/O 的初始化必须带
context.WithTimeout，例如db.PingContext(ctx, 2*time.Second) - 不要在
Do里log.Fatal()或panic，要返回error，让 handler 决定是返回 503 还是降级兜底 - 避免在
Do中调用其他包的重型初始化函数（比如某些 ORM 的schema.Load()），先查go tool compile -S main.go | grep "CALL.*init"看谁在暗中拖后腿
插件（plugin）延迟加载会放大首次访问延迟
plugin.Open 不是内存操作，它要 mmap 文件、解析 ELF 符号表、注册类型信息，实测单次耗时 0.8–2.3ms。如果你在 HTTP handler 里每次请求都 plugin.Open("./myplugin.so")，那首请求就不是慢，是不可控。
更糟的是，plugin.Lookup + 类型断言（如 sym.(func() error)）在热路径上叠加，会让单次调用比直连高 3–8 倍延迟。这不是 GC 问题，是 Go 运行时跨模块符号访问的固有成本。
必须做到：
- 启动时一次性
plugin.Open，全局复用*plugin.Plugin实例 - 启动时完成全部
Lookup，缓存为具体函数变量，例如：var runFunc = sym.(func() error) - 确保插件导出的结构体类型定义在主程序和插件共用的包里，否则断言失败且 panic 信息极难 debug
冷启动场景下，延迟加载可能掩盖真正瓶颈
在 Serverless 或 K8s Pod 启动这类冷启动场景中，你看到的“首次访问慢”，其实是多个延迟加载叠加的结果：配置加载慢 + DB 连接慢 + 插件加载慢 + 日志编码器初始化慢。它们各自只慢几十毫秒，合起来就是几百毫秒甚至秒级延迟。
真正容易被忽略的地方是：这些操作彼此之间没有依赖关系，完全可以并发初始化。但如果你全塞进一个 sync.Once 或顺序执行的 init() 函数里，就白白放弃了并行收益。
建议用 errgroup.Group 并发触发多个懒加载任务，再用 sync.Once 包裹最终的资源句柄（比如 *sql.DB），既保线程安全，又榨干 CPU。
