sync.Once 比手写双重检查更可靠，因其内置原子操作与互斥锁组合，天然解决内存可见性、指令重排和竞态问题，避免 nil panic、未初始化对象返回等错误，且性能优、行为稳定。
为什么 sync.Once 比手写双重检查更可靠
Go 标准库的 sync.Once 就是为单例初始化设计的，它天然解决内存可见性、指令重排、竞态执行等问题。手写双重检查（Double-Checked Locking）在 Go 中不仅没必要，还容易因缺少 unsafe.Pointer 或 atomic 配合而失效。
常见错误现象：nil 指针 panic、返回未完全初始化的对象、多次执行初始化函数。
-
sync.Once内部用原子操作 + 互斥锁组合，保证Do只执行一次且对所有 goroutine 可见 - 不用管
init顺序、编译器优化、CPU 缓存一致性这些底层细节 - 性能上几乎无额外开销：首次调用有锁开销，之后是纯原子读，比每次进锁快得多
用 sync.Once 实现并发安全单例的正确姿势
核心就三步：声明全局变量、声明 sync.Once、封装获取函数。别把初始化逻辑塞进包级变量赋值里，也别在 init() 函数里做带副作用的初始化。
典型场景：数据库连接池、配置加载器、日志实例等需要延迟初始化且全局唯一的服务对象。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var (
instance *Config
once sync.Once
)
<p>func GetConfig() <em>Config {
once.Do(func() {
instance = &Config{ /</em> heavy init */ }
})
return instance
}- 必须把
instance和once都声明为包级变量，不能放在函数内或结构体字段里 -
once.Do()里的函数不能返回错误，如有失败需自行处理（比如 panic 或内部重试） - 如果初始化可能失败且需暴露错误，建议改用带返回值的懒加载函数 +
sync.Once控制执行，而不是强行塞进Do
什么时候不该用 sync.Once 做单例
不是所有“只跑一次”的逻辑都适合套 sync.Once。它只保障执行一次，不负责生命周期管理、依赖注入或测试隔离。
常见误用场景：单元测试中无法重置单例状态、依赖外部服务且需 mock、初始化过程需传参或上下文。
- 测试时无法清空
sync.Once状态，导致测试间污染；应改用构造函数 + 显式初始化，由调用方控制 - 若初始化需要
context.Context或配置参数，sync.Once无法传递，得退回到带参工厂函数 - 某些依赖（如 gRPC 连接）本身已自带连接池和复用逻辑，再套一层单例反而增加耦合和调试难度
sync.Once 的底层行为和兼容性注意点
从 Go 1.0 开始 sync.Once 行为稳定，但它的实现细节会影响你对“完成”和“可见性”的理解：一旦 Do 返回，所有 goroutine 都能看到初始化后的结果，但不保证初始化函数内部所有写入都立即对其他 goroutine 可见——不过标准库已通过内存屏障处理了这点。
容易踩的坑：Do 执行期间 panic 会导致该 Once 永久卡死，后续调用直接返回，不再尝试初始化。
- panic 是致命的：一旦初始化函数 panic，
once.Do()后续永远不执行，也不会传播 panic - Go 1.21+ 支持
sync.OnceValues（实验性），用于带返回值的一次性计算，但尚未稳定，生产环境慎用 - 不要试图用
reflect或unsafe绕过sync.Once的状态检查——它没有导出字段，也没有重置接口
这事的关键在于接受 sync.Once 的契约：它只管“执行一次”，不管“怎么执行”“执行成啥样”。初始化失败就得靠你自己兜底，测试隔离就得靠设计让步，想传参就得换思路。没那么灵活，但足够稳。
