sync.once比手写双重检查更可靠，因其内置处理内存可见性、指令重排和初始化原子性，避免竞态、nil解引用及cpu缓存不一致问题，且初始化后无同步开销。
为什么 sync.Once 比手写双重检查更可靠
Go 标准库的 sync.Once 本质就是线程安全单例的终极解法，它内部已处理内存可见性、指令重排、初始化原子性等所有底层细节。自己用 sync.Mutex + if 判断实现双重检查，极易漏掉 unsafe.Pointer 或 atomic.LoadPointer 的正确用法，反而引入竞态。
常见错误现象：nil pointer dereference 或偶尔 panic，尤其在高并发初始化阶段；使用场景是全局配置加载、数据库连接池、日志实例等只应创建一次的对象。
-
sync.Once保证Do中函数最多执行一次，且后续调用直接返回，无需额外判空 - 不依赖指针比较或标志位轮询，规避了 CPU 缓存不一致风险
- 性能上比每次加锁判断快一个数量级，初始化后无同步开销
sync.Once 的典型用法与参数陷阱
核心就两步：声明一个 sync.Once 字段（通常在包级变量中），再在获取函数里调用其 Do 方法。关键在于传给 Do 的函数不能有参数、不能返回值，且必须通过闭包捕获外部变量来完成赋值。
容易踩的坑：Do 接收的是 func() 类型，若闭包里引用了未初始化的变量，会导致初始化逻辑静默失败；另外，Once 实例本身不可复制，必须是指针或包级变量，否则每次都是新实例。
立即学习“go语言免费学习笔记（深入）”；
- 必须用指针传递
sync.Once字段，比如var once sync.Once然后once.Do(...)是安全的，但若嵌入结构体并值拷贝，就失效 - 初始化函数里不要做耗时操作（如网络请求），否则会阻塞所有等待 goroutine
- 不要在
Do函数里调用另一个依赖本单例的初始化函数，可能死锁
var (
instance *Config
once sync.Once
)
<p>func GetConfig() *Config {
once.Do(func() {
instance = &Config{Port: 8080}
})
return instance
}不用 sync.Once 时，手写双重检查的最小安全写法
仅当需要延迟初始化 + 提前暴露指针 + 控制初始化时机（比如配合 DI 容器）时才考虑手动实现。此时必须用 atomic.Value 或 unsafe.Pointer 配合 atomic.CompareAndSwapPointer，普通布尔标志位完全不可靠。
性能影响明显：每次读取都要走原子操作，比 sync.Once 初始化后的纯内存访问慢；兼容性无问题，但 Go 1.16+ 才对 atomic.Pointer 提供泛型支持，旧版本需用 unsafe.Pointer。
- 必须用
atomic.LoadPointer读，atomic.CompareAndSwapPointer写，不能混用bool标志 - 初始化对象要先构造完成，再原子写入，避免其他 goroutine 读到部分初始化状态
- Go 1.19+ 推荐用
atomic.Pointer[T]替代unsafe.Pointer，类型安全且语义清晰
测试单例是否真正线程安全的实操方法
光看代码逻辑不够，必须用 go test -race 跑并发测试。重点不是验证“只创建一次”，而是验证“所有 goroutine 获取到的实例地址完全相同”且“无数据竞争”。
常见错误现象：测试通过但线上偶发 panic，往往是因为测试并发数太小，没触发竞态窗口；或者只测了获取逻辑，没覆盖初始化过程中的资源释放/重试路径。
- 用
sync.WaitGroup启动 100+ goroutine 并发调用获取函数，最后用map[uintptr]bool统计实例地址去重 - 在初始化函数里加入
time.Sleep(10 * time.Microsecond)拉长临界区，更容易暴露问题 - 务必添加
-race标志运行，Go 的 race detector 能捕获绝大多数内存可见性错误
实际落地时，95% 的场景直接用 sync.Once 就够了。难点不在写法，而在想清楚“这个单例到底该在哪个时机初始化”——是包加载时、第一次调用时、还是显式 Init 时。选错时机，再安全的实现也救不了设计缺陷。
