atomic.Value 不能替代 sync.Once 做延迟加载，因其仅保证读写原子性而不控制初始化时机与次数；多个 goroutine 可能并发 Store 导致重复初始化、资源泄漏或状态混乱，且无法保证“只执行一次”语义。
atomic.Value 本身不提供“延迟加载”能力，它只保证 Store 和 Load 的原子性。所谓“延迟加载”，是指值首次被需要时才构造、且仅构造一次——这本质上是单例 + 懒初始化问题，必须配合 sync.Once 使用。直接把 atomic.Value 当成懒加载容器会出错。
为什么 atomic.Value 不能替代 sync.Once 做延迟加载
atomic.Value 不做初始化控制，它只是个线程安全的“盒子”：你什么时候 Store，它就什么时候有值；没人 Store，Load 就返回 nil（对非指针类型会 panic）。它不会帮你判断“该不该创建”或“只创建一次”。
- 多个 goroutine 同时发现值为空，都会尝试
Store，但只有最后一个成功，前面的写入被覆盖 —— 这不是懒加载，是竞态写入 - 如果存储的是指针（如
*Config），而构造逻辑有副作用（如读文件、建连接），重复执行会引发资源泄漏或状态混乱 -
atomic.Value对类型敏感：第一次Store后，后续只能存同类型值；若懒加载逻辑中途改了返回类型，运行时 panic
正确组合：sync.Once + atomic.Value
标准做法是用 sync.Once 保证初始化逻辑只执行一次，再用 atomic.Value 承载初始化后的结果，供高并发读取。
-
sync.Once负责“第一次谁来造”，开销仅在初始化阶段； -
atomic.Value负责“造完后大家怎么安全读”，零锁、无内存屏障开销； - 二者分工明确，不重叠也不缺失
var (
configOnce sync.Once
configVal atomic.Value // 存 *Config
)
func GetConfig() *Config {
if v := configVal.Load(); v != nil {
return v.(*Config)
}
configOnce.Do(func() {
c := loadConfigFromDisk() // 可能耗时、有副作用
configVal.Store(c)
})
return configVal.Load().(*Config)
}
常见误用：用 Load 判断 + Store 竞争代替 Once
有人试图绕过 sync.Once，靠反复 Load 判空再 Store 实现“伪懒加载”，这是危险的：
- 即使加了
if configVal.Load() == nil，多个 goroutine 仍可能同时进入Store分支 -
atomic.Value.Store不是 CAS，不检查旧值；后 Store 的值直接覆盖前一个，导致部分 goroutine 初始化的资源未被释放 - 如果
loadConfigFromDisk()返回nil或错误，你无法区分是“还没初始化”还是“初始化失败”，逻辑更难维护
注意：atomic.Value 存的是值拷贝，不是引用安全
即使用了 sync.Once + atomic.Value，也要小心值本身的线程安全性：
立即学习“go语言免费学习笔记（深入）”；
- 存
map[string]string没问题，但外部不能直接修改这个 map ——atomic.Value只保护“替换整个 map”的动作，不保护 map 内部元素的读写 - 存
[]byte同理，底层数组可能被多个 goroutine 并发写；应存不可变结构，或确保使用者只读 - 绝对不要存含
sync.Mutex或sync.WaitGroup的结构体 ——sync.Mutex不可复制，Store会 panic
atomic.Value 解决的是“读写安全”，sync.Once 解决的是“执行安全”，两者缺一不可。把它们混为一谈，或者只用其一，都会在高并发下暴露竞态或资源泄漏。** 
