必须先Get再Watch且传WithRev，否则漏初始值；需WithPrefix监听目录、WithPrevKV获取旧值；Watch须在goroutine中消费，断连时检测ok==false并重建；配置更新须用atomic.Value保证原子性。
etcd clientv3 必须先 Get 再 Watch，且要传 WithRev
直接 Watch 会漏掉首次配置值，因为 etcd v3 的 watch 默认从当前 revision 开始，而新启动的服务很可能在配置写入之后才建立监听。常见错误是只调 client.Watch(ctx, "/config/app/")，结果服务起来后一直收不到初始值。
- 启动时先用
client.Get(ctx, "/config/app/")拉取全量，拿到resp.Header.Revision - Watch 时传
clientv3.WithRev(rev + 1)，确保从下一个 revision 开始监听 - 必须加
clientv3.WithPrefix()，否则只匹配完整 key；如监听/config/app/下所有子项，路径末尾不能少斜杠 - 建议同时加
clientv3.WithPrevKV()，方便对比旧值，避免重复处理或空更新
监听逻辑不能堵在 main goroutine 里
client.Watch() 返回的是阻塞 channel，如果在 main 或 init 里直接 for range watchChan，整个程序就卡住不动了——这不是 bug，是设计如此。很多新手把监听写进 init() 或直接丢 main 里，结果服务根本起不来。
- 必须用
go func() { ... }()单独起 goroutine 消费watchChan - 回调里别做耗时操作：解析 JSON、重连 DB、调外部 API 都得发到 worker channel 或异步触发
- Watch 连接断开时，
watchChan会关闭，需检测ok == false并重建 client 和 Watch（实际中常配合 backoff 重连） - 不要用
time.Sleep模拟重试，用select+time.After控制间隔更可控
本地缓存更新必须原子，不能裸写结构体字段
配置热更新最危险的坑不是收不到事件，而是“半新半旧”状态：比如 Config.DB.Host 已更新，Config.DB.Port 还是旧值，下游组件拿这个结构体去 dial，大概率连不上。
- 推荐用
atomic.Value存 *Config 指针，每次变更都new(Config)后Store()，读取用Load().(*Config) - 若用
sync.RWMutex，读操作必须RLock()/RUnlock()，写操作Lock()/Unlock()，且锁粒度要包住整个结构体赋值 - 绝对不要在 watch 回调里直接修改全局变量字段，比如
cfg.Timeout = newTimeout—— 这是并发不安全的 - 结构体所有字段必须首字母大写（导出），且不提供 setter 方法，保证“构造即冻结”
viper 不是万能胶，它不自动响应 etcd 变更
很多人以为 viper.AddRemoteProvider("etcd", "localhost:2379", "/config") 就能热更新，其实这只是单次拉取；viper.WatchRemoteConfig() 早已被标记为 deprecated，官方不维护。真正生效的，是你自己写的监听+解析逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 收到
EventTypePut后，先检查ev.Kv != nil && len(ev.Kv.Value) > 0，防空 panic - 用
json.Unmarshal()或yaml.Unmarshal()解析ev.Kv.Value，失败就跳过，别log.Fatal或 panic - 要用
viper.ReadConfig(bytes.NewReader(data))替换内存配置，不是viper.Unmarshal()—— 后者不刷新内部configMap - 如果 etcd 存的是扁平 key（如
/config/app/log_level），需要先聚合所有监听 key 的 value，再统一反序列化
