sync.Once.Do 能保证只执行一次，因其用 uint32 原子变量配合 atomic.CompareAndSwapUint32 实现无锁判断；一旦标记完成，后续调用直接返回。
sync.Once.Do 为什么能保证只执行一次
因为 sync.Once 内部用一个 uint32 原子变量记录是否已执行，配合 atomic.CompareAndSwapUint32 实现无锁判断；一旦标记为“已完成”，后续所有 Do 调用直接返回，不加锁、不阻塞、不重复调用传入函数。
常见错误现象：Do 传入的函数里 panic，会导致 Once 永远卡在“未完成”状态——下次调用仍会重试，但 panic 会再次发生。这不是 bug，是设计如此：失败不记为完成。
- 必须确保传入
Do的函数是幂等且可安全重入的（至少能扛住 panic） - 不要在
Do里做需要外部上下文校验的初始化（比如依赖 config 文件存在），否则 panic 后整个单例不可用 - 如果初始化逻辑可能失败，应在函数内部捕获 panic 或用 error 返回并主动处理，而不是依赖
Once自动兜底
全局单例变量怎么声明才安全
不能把单例指针声明为包级变量后直接赋值，比如 var db *sql.DB = initDB() —— 这会在 init 阶段执行，无法控制时机，也无法处理初始化失败。
正确做法是声明未初始化的变量 + 懒加载函数：
var (
instance *MyService
once sync.Once
)
func GetInstance() *MyService {
once.Do(func() {
instance = &MyService{...} // 或调用复杂初始化函数
})
return instance
}
- 变量必须是包级导出（首字母大写）或按需封装访问函数，避免直接暴露未初始化的指针
- 不要把
sync.Once放进结构体里作为字段——它不是线程安全的复制候选，也不能跨实例复用 - 如果单例需要参数（如配置），请把参数传给初始化函数，而不是塞进闭包捕获局部变量（易引发内存泄漏或竞态）
和 init 函数比，sync.Once 适合什么场景
init 是包加载时强制执行，不可跳过、不可重试、无法感知依赖是否就绪；sync.Once 是运行时按需触发，可控、可组合、可容错。
典型适用场景：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 数据库连接池初始化（要等配置加载完、网络就绪）
- 第三方 SDK 客户端构建（依赖环境变量或命令行参数）
- 带健康检查的懒加载资源（比如先尝试 connect，失败则 fallback 或报错）
反例：纯常量计算、无副作用的 struct 初始化——用 init 或字面量更轻量；强行套 Once 反而增加原子操作开销。
多个单例之间有依赖时怎么避免死锁
如果 A 的初始化要调用 GetB()，而 B 的初始化又反过来依赖 GetA()，sync.Once 会卡死：两个 goroutine 分别在各自的 Do 里等待对方完成。
根本原因：sync.Once 不支持递归检测，也没有超时或中断机制。
- 提前梳理依赖拓扑，确保初始化顺序是 DAG（有向无环）
- 把强依赖拆成两阶段：先构造空壳（不依赖对方），再通过显式
Setup()方法注入依赖 - 绝对不要在
Once.Do回调里同步调用另一个单例的获取函数——哪怕看起来“不会循环”，也容易在重构后意外引入
最常被忽略的一点：测试时用 Reset() 重置 sync.Once 看似方便，但它是非并发安全的，只能在单测 setup 阶段用，且必须确保没有其他 goroutine 正在或即将调用 Do。生产代码里别碰 Reset。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
