热加载本质是监听文件变化并原子替换内存配置，需用fsnotify监听变更、viper.ReadInConfig解析、atomic.Value或sync.RWMutex保障线程安全、校验失败时保留旧配置并记录错误。
配置热加载本质是监听文件变化 + 安全替换内存配置
Go 本身不提供“自动热加载”机制，所谓热加载其实是程序自己监听配置文件（如 config.yaml 或 app.json）的变更事件，解析新内容，并在保证线程安全的前提下原子性地替换旧配置。关键不是“语言支持”，而是你如何设计读取、校验、切换、通知这四个环节。
viper.Load() 不等于热加载，必须配合 fsnotify 监听
viper.Load() 只是一次性加载，调用它不会触发自动重载。真正实现热更新需要：fsnotify.Watcher 监控文件系统事件，再在 Write 或 Chmod 事件触发时，调用 viper.ReadInConfig() 重新解析，并做有效性校验。
- 不要直接监听
os.File句柄，它无法感知外部修改 - 推荐用
fsnotify.NewWatcher()，注意处理Remove和Rename事件（编辑器保存时常先写临时文件再替换） -
viper.WatchConfig()底层就是封装了fsnotify，但只适用于单配置文件场景；若配置分散在多个路径或需自定义校验逻辑，建议手动控制
配置切换必须用 atomic.Value 或 sync.RWMutex 保护
多 goroutine 并发读配置时，直接赋值全局变量（如 cfg = newCfg）会导致读到中间态——部分字段已更新、部分未更新。必须确保“整个配置结构体”的替换是原子的。
- 简单场景：用
sync/atomic.Value存储指针，Store()和Load()天然原子 - 复杂场景：用
sync.RWMutex包裹读写，写操作加Lock()，读操作用RUnlock()，避免写期间阻塞所有读 - 切忌在热加载回调里直接修改 struct 字段（如
cfg.Port = newPort），这破坏一致性
热加载失败时必须保留旧配置并记录错误，不能 panic 或静默丢弃
配置文件语法错误、字段缺失、类型不匹配等都可能发生在运行时。一旦解析失败，viper.Unmarshal() 返回 error，此时若强行覆盖，服务可能因读到 nil 字段而 panic。
立即学习“go语言免费学习笔记（深入）”；
- 必须把新配置解析结果先存到临时变量，校验通过后再切换
- 日志要明确记录错误位置，例如：
"failed to reload config: yaml: unmarshal errors:\n line 12: cannot unmarshal !!str `abc` into int" - 可考虑加 fallback 机制，比如连续 3 次加载失败后自动回滚到上一个有效版本（需额外缓存历史快照）
最容易被忽略的是信号量竞争：当多个 goroutine 同时触发重载（比如编辑器高频保存），没加互斥会导致多次解析、多次切换，甚至配置状态来回震荡。哪怕用 atomic.Value，解析过程本身也得串行化。
