Go语言中“延迟加载”与“按需加载”本质相同，均指将初始化推迟至首次使用时执行；前者强调时间延迟，后者强调触发条件，实践中统一采用sync.Once、sync.Lazy或lazy.Group等机制实现。
是，Go语言中“延迟加载”和“按需加载”在工程实践里指向同一类行为：把初始化动作从启动阶段往后推，到第一次真正需要时才执行。但二者侧重点略有不同——延迟加载强调时间维度（晚点做），按需加载强调触发条件（有需求才做）。实际写代码时，你用的都是同一套机制。
sync.Once 是最常用也最容易出错的延迟加载方式
它保证函数只执行一次，适合单例、全局配置、DB连接等场景。但很多人忽略它的阻塞特性：如果初始化函数耗时或失败，所有后续 goroutine 都会卡在 Once.Do() 上等待，而不是立即返回错误或降级。
- 别在
Once.Do()里做网络请求或读大文件——首次调用会被卡住 - 初始化失败后，
sync.Once不会重试，也不会暴露错误；得自己加字段存错，比如err error和inited bool - 并发调用时，只有一个 goroutine 执行初始化，其余阻塞等待；这没问题，但得确保初始化函数本身是线程安全的
Go 1.21+ 的 sync.Lazy 更安全、更语义清晰
sync.Lazy 是对 sync.Once 的封装升级，用值语义自动管理初始化状态，还内置了错误传播能力。它不是简单替换，而是解决 sync.Once 缺失的关键能力：
- 初始化函数可返回
(T, error)，调用方能直接拿到结果或错误，不用额外字段判断 - 初始化失败后，下次调用仍会重试（除非你显式缓存了错误）
- 写法更简洁：
l := sync.Lazy[http.Client]{Fn: func() (http.Client, error) { return http.Client{}, nil }}
lazy.Group 用于需要重试、超时、隔离的按需加载场景
当你要加载的是外部服务（比如下游 HTTP 接口、gRPC 实例），它可能暂时不可用，这时不能让所有请求都卡死在 sync.Once 或 sync.Lazy 上。用 golang.org/x/sync/singleflight 或自定义 lazy.Group 才合适：
立即学习“go语言免费学习笔记（深入）”；
-
lazy.Group不是标准库，常来自社区封装，核心是支持失败后后台重试 + 前置降级响应 - 典型结构：首次调用返回一个占位
chan或error，同时异步启动初始化；成功后广播结果，失败则记录并允许下次再试 - 别把它和
sync.Once混用——前者管“怎么容错”，后者管“只做一次”，职责不同
真正容易被忽略的是初始化函数的副作用边界：比如在 init() 里解析 YAML 配置是安全的，但若这个 YAML 里包含需要联网拉取的远程 URL，那就已经越界了。延迟加载不是换个地方写阻塞逻辑，而是重新思考“什么才算真正需要”。
