sync.Once 是唯一靠谱的“只执行一次”方案，因其底层用原子操作+互斥锁双重保障，确保并发调用 Do 时函数最多执行一次且所有调用者均等待完成。
为什么 sync.Once 是唯一靠谱的“只执行一次”方案
手动加锁 + 布尔标记看似能实现，但极易漏掉竞态：两个 goroutine 同时读到 done == false，都进临界区。而 sync.Once 底层用原子操作 + 互斥锁双重保障，确保无论多少 goroutine 并发调用 Do，函数最多执行一次，且所有调用者都会等到它完成（哪怕自己没触发执行）。
常见错误现象：sync.Once 的 Do 参数必须是 func()，传入带参数或返回值的函数会编译报错；误以为 Once 能重置（它不能，一旦执行过，后续调用直接返回）。
- 使用场景：全局配置加载、单例初始化、信号处理注册、DB 连接池首次建立
- 性能影响极小：未执行前只是原子读，执行后变成普通内存读；比手写锁更轻量
- 兼容性无风险：自 Go 1.0 起稳定存在，无版本差异
sync.Once.Do 的参数陷阱和正确写法
你不能直接把带参函数塞进去，比如 once.Do(loadConfig("prod")) —— 这会立刻执行 loadConfig，且结果被忽略（因为返回值不匹配 func() 类型）。必须传一个闭包或无参函数字面量。
正确做法是把逻辑包在匿名函数里，参数通过闭包捕获：
立即学习“go语言免费学习笔记（深入）”；
once.Do(func() {
loadConfig("prod")
})
如果需要捕获变量，注意闭包变量生命周期。别这么写：
for _, env := range []string{"dev", "prod"} {
once.Do(func() { loadConfig(env) }) // ❌ env 总是最后一个值
}
应该显式传参或复制变量：
env := env
once.Do(func() { loadConfig(env) }) // ✅
并发调用 sync.Once.Do 时，谁在等？等多久？
所有未触发执行但已进入 Do 的 goroutine，会阻塞直到那个“幸运 goroutine”完成传入函数。不是轮询，也不是忙等，而是走 Go runtime 的同步原语（底层是 futex 或 semaphore），完全交由调度器管理。
这意味着：如果你的初始化函数耗时 2 秒，那么在这 2 秒内所有其他 goroutine 在 Do 处挂起，2 秒后全部唤醒并继续执行——没人重复执行，也没人跳过等待。
- 不会 panic：即使初始化函数 panic，
sync.Once仍视为“已执行”，后续调用不再执行，也不会传播 panic - 无法区分失败：没有暴露执行是否成功的状态，失败需靠外部变量或 error 返回值自行记录
- 没有超时控制：不支持 context，超时需在外层封装（比如用
sync.Once+sync.Mutex+ 手动状态标记）
源码里真正关键的那行原子操作
sync.Once 核心就靠一个 uint32 字段 done 和 atomic.CompareAndSwapUint32。第一次调用时，尝试把 done 从 0 改成 1；成功者获得执行权，失败者去等 done 变成 1。
真正容易被忽略的是：这个原子操作只决定“谁来执行”，不负责“执行完通知”。通知靠的是 sync.Mutex —— 执行者执行完会 unlock，所有等待者才能继续。所以它其实是原子操作 + 锁的组合，不是纯无锁。
这也解释了为什么不能靠反复读 done 来判断是否完成：没有内存屏障保证可见性，必须依赖锁的释放-获取语义。
