sync.Once 底层用 uint32 状态字+原子操作+互斥锁实现，非双重检查锁；其 Do 方法分快、竞态、慢三路径执行，确保函数同步且仅执行一次，但不保证内部异步行为完成。
sync.Once 的底层不是双重检查锁
很多人看到 sync.once 的「只执行一次」语义，就联想到 java 里的双重检查锁（dcl），但 go 标准库的实现完全没用到 volatile + synchronized 组合，也不依赖内存屏障的手动插入。它用的是更轻量、更确定的方式：一个 uint32 状态字 + 原子操作 + 互斥锁兜底。
核心逻辑是：先原子读状态，如果是已执行（done == 1），直接返回；否则尝试原子 CAS 将状态从 0 改为 1，成功者获得执行权，其他人阻塞等待——这本质上是「一次性的自旋+阻塞混合调度」，不是传统 DCL。
为什么不能自己手写双重检查锁来模拟 Once
在 Go 中试图用 sync.Mutex + 普通 bool 变量 + 两次 if 判断来模拟，会遇到两个硬伤：
- Go 编译器和 CPU 都可能重排序读写操作，导致未初始化完成的对象被其他 goroutine 提前看到（即「部分构造对象逸出」）
- 没有内存屏障保证，第一次 if 看到
initialized == true，不代表后续字段读取也已同步可见
sync.Once 内部用 atomic.LoadUint32 和 atomic.CompareAndSwapUint32 强制建立 happens-before 关系，这是手动写锁无法安全替代的。
Do 方法调用时的实际行为路径
调用 once.Do(f) 时，实际走三条路径之一：
- 快路径：状态为 1 → 直接 return，零开销
- 竞态路径：状态为 0，CAS 成功 → 加锁、执行
f()、设状态为 1、广播唤醒等待者 - 慢路径：状态为 0，CAS 失败（说明别人已抢到）→ 进入条件等待队列，直到状态变为 1 被唤醒
注意：f() 是在锁保护下执行的，所以即使传入的函数有副作用（比如初始化全局 map），也不会并发重复执行；但若 f() panic，sync.Once 会 recover 并仍标记为 done —— 这意味着失败后不会重试，调用方需自行处理初始化失败逻辑。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见误用：在 Do 里启动 goroutine 或做异步初始化
sync.Once.Do 的设计契约是「同步执行且完成后再返回」。如果在 f 中启动 goroutine 并立即返回，那么 Do 调用完时初始化工作大概率还没真正做完，其他 goroutine 会误以为已就绪。
例如这段代码是危险的：
once.Do(func() {
go func() {
data = heavyLoad() // 实际初始化发生在后台
}()
})
正确做法是让 f 同步完成所有关键初始化，或者把异步逻辑封装进返回值（如 *sync.Once 配合 sync.WaitGroup 或 channel），不要指望 Do 自身提供异步语义。
真正容易被忽略的是：once 的「once」只针对函数调用动作本身，不保证函数内部行为的原子性或完成性——这点得靠使用者自己守规矩。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
