sync.once 比手写双重检查锁更安全，因其内部用 atomic.loaduint32 和 compareandswapuint32 配合内存屏障，避免了编译器重排和 cpu 乱序导致的“半初始化”问题。
为什么 sync.Once 比手写双重检查锁更安全
Go 里手动实现双重检查锁（Double-Checked Locking）极易出错，根本原因在于编译器重排和 CPU 乱序执行可能让对象“半初始化”状态被其他 goroutine 看见。而 sync.Once 内部用 atomic.LoadUint32 + atomic.CompareAndSwapUint32 配合内存屏障（runtime/internal/atomic 底层保证），天然规避了这个问题。
常见错误现象：nil pointer dereference 或结构体字段为零值，即使你确认 init 函数已执行过；本质是未加内存屏障，导致字段写入未对其他 P 可见。
- 永远优先用
sync.Once初始化单例、全局配置、连接池等 —— 它轻量、无锁路径快、语义清晰 - 不要在
sync.Once.Do回调里做耗时操作（如网络请求），会阻塞所有后续 goroutine 直到完成 -
sync.Once不可重置，也不支持带返回值的初始化；若需失败重试或返回 error，请自行包装
手写双重检查锁时 atomic.LoadPointer 和 atomic.CompareAndSwapPointer 怎么配对用
如果非得手写（比如要控制初始化时机或复用已有 mutex），必须用原子指针操作 + 显式内存屏障，且初始化逻辑必须在加锁后再次检查。
关键点：第一次读用 atomic.LoadPointer（带 acquire 语义），写入用 atomic.StorePointer（带 release 语义），而 CompareAndSwapPointer 自带完整屏障。不能混用 int32 原子变量模拟指针就位标志 —— 指针和整数的内存对齐与可见性保障不同。
立即学习“go语言免费学习笔记（深入）”；
- 初始化前：声明
var p unsafe.Pointer，配合var once sync.Once或自定义 flag + mutex - 读取路径：先
atomic.LoadPointer(&p)，非 nil 则直接返回；否则加锁，再查一次atomic.LoadPointer(&p) - 写入路径：构造好对象后，用
atomic.StorePointer(&p, unsafe.Pointer(obj))，**不能只写 flag** - 务必避免把
unsafe.Pointer转成*T后再取地址传给StorePointer—— 这会触发 Go 的逃逸分析误判，导致对象被提前回收
sync.Once 在热更新场景下为什么不适用
sync.Once 设计目标是“仅一次”，它不提供重置、替换或条件重初始化能力。如果你需要运行时热加载配置、切换数据库连接、或根据环境变量动态初始化，硬套 sync.Once 会导致旧实例无法释放、新配置不可达。
典型使用场景：微服务启动时加载 YAML 配置并构建 *sql.DB，但后续希望 reload；或者 gRPC Server 启动后根据 etcd 变更调整限流策略。
- 替代方案：用
atomic.Value存储可变对象（如*Config），配合外部信号（os.Signal）或 watch 机制触发更新 -
atomic.Value的Store是线程安全的，但要求存入对象本身不可变（即 new Config() 后不再修改其字段），否则仍需额外锁 - 注意
atomic.Value的Load返回 interface{}，类型断言失败会 panic；建议封装一层带类型检查的 Get 方法
Go 1.20+ 中 atomic 包新增的 Bool / Int64 类型有什么实际影响
Go 1.20 引入 atomic.Bool、atomic.Int64 等类型，不是语法糖，而是明确禁止了对底层 uint32 的误用（比如拿 int32 做 atomic.AddInt64），也消除了 unsafe.Pointer 转换的必要性。
性能上无差异，但兼容性和可读性提升明显：以前写 atomic.StoreInt32(&flag, 1)，现在可写 flag.Store(true)；且 atomic.Bool 的 zero value 就是 false，不用显式初始化。
- 新项目直接用
atomic.Bool替代int32标志位，尤其适合开关类逻辑（如是否启用 metrics） - 注意
atomic.Pointer[T]是 Go 1.19 加入的，比atomic.LoadPointer更类型安全，推荐用于单例缓存指针 - 不要试图对
atomic.Int64做结构体内嵌（如type Counter struct { val atomic.Int64 }），它的字段不可导出，必须通过方法访问
真正容易被忽略的是：无论用 sync.Once 还是手写原子操作，只要初始化函数里引用了外部变量（尤其是闭包捕获的局部变量），就可能造成意外的内存泄漏或状态污染。检查 init 函数的闭包环境，比纠结用哪个原子操作更重要。
