atomic.Value 不能直接存原始类型，必须用指针（如*Config）或可比较结构体封装；每次更新需构造全新不可变实例并Store整个指针，读取时须判空并显式类型断言。
atomic.Value 不能直接存原始类型配置变量
直接把 int、string 或结构体值塞进 atomic.Value 是错的——它只允许存储可寻址的类型（即指针、接口、切片等），且要求类型完全一致。你不能先 Store(&cfg)，再 Load() 出来当 Config 值用，必须始终用指针或接口包装。
正确做法是让配置本身以指针形式流转：*Config。这样 atomic.Value 存的是指针地址，Load() 返回的也是同一类型的指针，安全且零拷贝。
- 错误写法：
var v atomic.Value; v.Store(Config{Port: 8080})→ 运行时 panic - 正确写法：
v.Store(&Config{Port: 8080})，后续cfg := v.Load().(*Config) - 如果 Config 字段多或含 map/slice，务必确保它是不可变的（或深拷贝后替换），否则并发读写内部字段仍会出问题
热加载必须配合配置监听 + 安全替换逻辑
atomic.Value 本身不感知变化，它只是个线程安全的容器。热加载的关键在于：谁触发更新？怎么保证新旧配置切换不中断服务？
典型流程是启动一个 goroutine 监听文件变更（如 fsnotify）或接收信号（如 SIGHUP），解析新配置后，构造新 *Config 实例，再调用 Store() 替换。注意：不要复用旧指针修改字段，必须新建实例。
- 避免在原
*Config上改字段：current.Port = 9000→ 并发读可能看到中间态 - 必须新建：
newCfg := &Config{Port: 9000, Timeout: c.Timeout}; v.Store(newCfg) - 建议在
Store()前做校验（如端口范围、必填字段），失败则跳过替换，保留旧配置
读取配置时要处理 nil 指针和类型断言失败
Load() 返回 interface{}，强制类型断言 (*Config) 是常见 panic 来源。尤其在初始化完成前或热加载出错时，atomic.Value 可能还没被 Store() 过，此时 Load() 返回 nil 接口，断言成 *Config 会 panic。
- 安全读法：
if cfgI := v.Load(); cfgI != nil { cfg := cfgI.(*Config) } - 更健壮写法（推荐）：
if cfgI := v.Load(); cfgI != nil { if cfg, ok := cfgI.(*Config); ok { ... } } - 初始化时务必先
Store()一个默认或有效配置，避免首次Load()就 panic
和 sync.RWMutex 对比：性能高但灵活性低
用 atomic.Value 替代读写锁，主要赢在无锁、读路径极致轻量（单条 CPU 指令）。但代价是：每次更新都要分配新对象，且无法实现“读期间禁止更新”这类细粒度控制。
如果你的配置极小（比如就一个 bool 开关），直接用 atomic.Bool 更合适；如果配置结构大且更新频繁，要注意 GC 压力——旧配置对象不会立刻回收，得等所有 goroutine 完成本次读取。
- 适合场景：配置整体替换、读远多于写、结构稳定（如 server 地址、超时值）
- 不适合场景：需要局部更新（如只改某个字段）、配置含大量 runtime 包装对象（如
sync.Mutex）、或要求强一致性（如“更新期间禁止任何读”） - 别忘了加注释说明：这个
atomic.Value存的是*Config，不是Config，否则接手人很容易踩坑
