Atomic.Value 不能直接存储基本类型，必须使用指针（如*int）或可复制结构体；其内部依赖类型一致性校验和sync.RWMutex，并非完全无锁，适用于配置热更新等低频写、高频读场景。
Atomic.Value 不能直接存基本类型，必须用指针或包装结构体
Go 的 sync/atomic.Value 只允许存储满足 unsafe.Pointer 兼容性的类型，但实际限制更严：它要求值可被原子复制（即不包含不可复制字段），且底层依赖 reflect.TypeOf 的可比较性判断。直接存 int、string 或 struct{} 会 panic。
- 常见错误现象：
panic: sync/atomic: store of inconsistently typed value into Value - 正确做法：统一用指针，比如
*int、*MyConfig；或者封装成可复制的结构体（字段全为可复制类型） - 不要试图绕过类型检查：哪怕两次
Store的值是同一类型但不同变量地址，只要 Go 运行时检测到类型描述符不一致，仍会 panic - 性能影响：指针存储本身无额外开销，但需注意 GC 压力——如果高频更新小对象并用指针包裹，可能增加逃逸和堆分配
Load 和 Store 必须配对使用相同类型，且不能混用接口和具体类型
一旦第一次 Store 了一个 *Config，后续所有 Load 都必须断言为 *Config；若某处误写成 interface{} 再转回，运行时会报错。
- 典型翻车场景：在日志中间件里把
v.Load()直接传给fmt.Printf("%v", ...)，看似没问题，但下一次Store换了类型就崩 - 安全写法：始终用显式类型断言，如
v.Load().(*Config)；配合if cfg, ok := v.Load().(*Config); ok { ... } - 接口类型陷阱：存
io.Reader接口值本身可以，但若先存*bytes.Buffer，再存*strings.Reader，虽都实现io.Reader，但底层类型不同，会触发 panic
Atomic.Value 不是万能替代 Mutex，高竞争下仍有锁开销
很多人以为 Atomic.Value 是纯无锁结构，其实它内部用了读写锁（sync.RWMutex）来保护类型一致性校验和首次加载路径。只有在类型未变、且已缓存类型信息后，Load 才走真正无锁快路径。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 性能关键点：首次
Load后，后续同类型Load是原子读内存；但每次Store都要加锁 + 类型比对 + 复制 - 适用场景：配置热更新、全局只读对象切换（如 logger 实例、codec 实例），不适合高频读写计数器类需求
- 对比
atomic.Int64：后者是真无锁，但只支持基础整型；Atomic.Value换来的是任意类型的灵活性，代价是锁和反射开销
跨 goroutine 更新时，务必确保旧值不再被使用再丢弃
Atomic.Value 只保证“替换”操作的原子性，不管理旧值生命周期。如果新值引用了旧值的字段（比如切片底层数组），而旧值又被其他 goroutine 持有并修改，就会出现数据竞争。
立即学习“go语言免费学习笔记（深入）”；
- 典型问题：用
Store(&Config{Data: old.Data})复用旧切片，但没同步锁住old.Data的写入 - 安全做法：深拷贝可变内容，或确保被存对象本身不可变（如
struct字段全为const或只读字段） - 容易忽略的一点：即使你用了
Store，GC 也不会立刻回收旧值——它可能还在某个 goroutine 栈上活着，所以别假设“换掉就安全了”
