viper.WatchConfig() 在分布式环境失效，因其依赖本地文件系统监听，无法感知 etcd/Nacos/Apollo 等远端配置中心变更；需用对应 SDK（如 etcd Watch、Nacos Subscribe、Apollo 轮询+ETag）在独立 goroutine 中监听，并用 sync.RWMutex 安全更新配置。
为什么直接用 viper.WatchConfig() 在分布式环境会失效
因为 viper.watchconfig() 依赖本地文件系统 inotify 或 fsnotify，它根本不知道远端配置中心（比如 etcd、nacos、apollo）发生了变更。一旦配置从服务端更新，本地进程压根收不到通知，更谈不上热加载。
真正要做的，是把“监听远端变更”和“安全更新本地配置实例”两件事串起来，且不能阻塞主业务逻辑。
- etcd 用
Watch()长连接监听 key 前缀变化；Nacos 用Subscribe()注册回调；Apollo 则需轮询/configs接口 + ETag 对比 - 所有监听逻辑必须运行在独立 goroutine，避免卡住初始化流程
- 配置结构体更新时，不能简单赋值——要防止读写竞争，推荐用
sync.RWMutex包裹读操作，写操作加锁后原子替换指针
如何用 etcd/clientv3 实现低延迟配置监听
etcd 的 Watch 机制天然适合做配置变更推送，但要注意：默认 Watch 是流式响应，一次连接可接收多次事件，别误写成每次变更都新建 client。
关键点在于处理 mvccpb.EventType_PUT 和 mvccpb.EventType_DELETE，尤其是 DELETE 要考虑兜底默认值或跳过更新，避免配置被清空。
- 使用
client.Watch(ctx, "/config/", clientv3.WithPrefix())监听整个配置目录 - 在 Watch 循环里用
select { case wresp := 消费事件，不要用 <code>for range直接遍历 channel（会 panic） - 每次收到 PUT 事件后，调用
client.Get(ctx, event.Kv.Key)获取最新值，再反序列化进结构体——别直接信任event.Kv.Value，它可能被截断或编码异常 - Watch 连接断开时（
wresp.Err() != nil），应重试并重新建立 watch，建议加指数退避，避免打爆 etcd
热更新时怎么避免配置正在被读取就突然替换
最常见错误是：一个 goroutine 正在执行 conf.DB.Timeout，另一个 goroutine 却执行了 currentConf = newConf，导致字段读取出现半新半旧状态，甚至 panic（如果结构体字段类型变了）。
- 不要用普通 struct 变量存配置，改用指针：
var currentConf *Config - 读配置统一走函数封装，例如
func GetConfig() *Config { rmu.RLock(); defer rmu.RUnlock(); return currentConf } - 写配置时先 deep copy 新配置，校验通过后再
wmu.Lock(); currentConf = copied; wmu.Unlock() - 如果配置含切片或 map，务必深拷贝——
json.Marshal + json.Unmarshal最稳妥，别用浅层赋值
要不要支持配置项级别的变更回调
全量 reload 足够简单，但有些场景需要更细粒度响应：比如只在 log.level 改变时重置 logger，而不是重启整个 HTTP server。
可行做法是维护一张 map[string]func(interface{})，键为 JSONPath 形式的路径（如 "server.port"），值为回调函数。解析 Watch 到的变更 key 后，匹配路径并触发对应回调。
- etcd key 是扁平的，比如
/config/server/port，可按/分割后拼成"server.port" - 回调函数签名统一为
func(interface{})，传入反序列化后的原始值（int64,string,bool），由业务自己类型断言 - 注意：回调里禁止做耗时操作（如 HTTP 请求、数据库写入），否则会拖慢 Watch 循环，建议投递到 worker channel 异步处理
