sync.Once通过uint32类型的done字段配合atomic.LoadUint32和atomic.CompareAndSwapUint32实现无锁快速路径，仅首次CAS成功者执行函数，后续调用直接返回；panic后done仍置1，不可重试。
Sync.Once 是怎么保证只执行一次的
核心靠一个 uint32 类型的 done 字段 + 原子操作，不是锁也不是 channel。它不阻塞其他 goroutine，而是让后续调用快速返回，只有第一个调用者真正执行函数。
源码里关键逻辑就两步：atomic.LoadUint32(&o.done) 先查是否已执行；如果没执行，就用 atomic.CompareAndSwapUint32 尝试抢占，成功了才去执行 o.m.Do(f) 里的函数。
容易踩的坑：
-
Once不处理 panic：如果Do里的函数 panic，done仍会被设为 1，后续调用直接返回，不会重试也不会报错 - 不能复用：
Once实例一旦done == 1，就永远不可逆，别把它当“可重置单次开关”用 - 不适用于需要参数化初始化的场景：它只接受无参函数，传参得靠闭包或外部变量，要注意变量捕获时机
用 Sync.Once 实现线程安全的单例时为什么不能直接 new struct
因为 Go 没有类构造器概念，单例本质是“首次访问时初始化一个全局变量”，而 Once 只负责控制执行时机，不负责对象生命周期管理。你得自己配好指针、初始化逻辑和导出方式。
立即学习“go语言免费学习笔记（深入）”；
典型写法是定义一个私有全局变量 + 导出的获取函数：
var (
instance *Config
once sync.Once
)
func GetConfig() *Config {
once.Do(func() {
instance = &Config{Port: 8080, Timeout: 5}
})
return instance
}
常见错误：
- 把
instance声明成值类型（比如var instance Config），会导致每次返回副本，失去单例语义 - 在
init()里直接初始化，绕过了Once，但失去懒加载能力，且无法处理依赖未就绪的情况 - 多个
Once实例混用，比如每个方法都 new 一个sync.Once，那就完全没意义了
Once.Do 传入函数里捕获外部变量的风险
闭包捕获的变量如果在 Do 执行前被修改，会导致单例初始化结果不符合预期。尤其在 init 阶段或并发注册时容易出问题。
比如这样写就有隐患：
var port int
port = 3000
once.Do(func() { instance = &Server{Port: port} }) // port 可能被改写
更稳妥的做法是把依赖项在闭包外确定好，或者用参数化构造：
- 提前计算好所有初始化所需值，再传进闭包
- 用工厂函数封装，比如
newServer(port)，避免自由变量 - 如果依赖配置文件或环境变量，确保读取动作发生在
Do内部，而不是外面先读再闭包捕获
为什么不用 sync.Mutex 或 atomic.Bool 替代 Once
sync.Mutex 会带来持续锁开销，哪怕单例已创建；atomic.Bool 虽轻量，但没法解决“执行中”的竞态——多个 goroutine 同时发现未执行，都可能进入临界区。
Once 的精妙在于用 CAS 实现“抢占式执行权”，配合 done 标志实现无锁快速路径。它的性能曲线是：第一次略慢（CAS + 函数调用），后续接近原子读，比任何手写锁都高效。
注意点：
-
Once不是通用同步原语，只适合“一次性初始化”场景，别拿它做信号量或条件等待 - Go 1.21+ 支持
sync.OnceValue，适合带返回值的初始化，但目前还没进标准库主干，别误当成已有特性 - 测试时别 mock
Once本身——它应该被视为基础设施，重点测的是它保护的初始化逻辑是否幂等、是否按需触发
真正难的从来不是写个 Once.Do，而是判断“这个初始化逻辑到底该不该放进去”：它得是无副作用、可重入（至少失败时能重试）、且不依赖外部 mutable 状态的。否则，Once 只会让问题更隐蔽。
