Watch必须用for range持续消费，不能只调一次Watch()；需先Get初始配置再WithRev启动Watch，直接解析Event.Kv避免竞态，禁用progress notify，错误时重连并续订revision。
Watch 必须用 for range 持续消费，不能只调一次 Watch()
etcd 的 clientv3.Watcher.Watch() 返回的是一个 clientv3.WatchChan，本质是持续推送的事件流通道。如果只调一次、不循环读取，goroutine 会立刻退出，后续变更完全收不到——且无任何错误提示，静默失效。
- 必须用
for range watchChan长期监听，每个clientv3.WatchResponse的Events字段可能含多个事件（比如批量写入），不能只取Events[0] - 每次循环开头要检查
wresp.Err()：若为context.Canceled或context.DeadlineExceeded，说明上下文已结束；若为clientv3.ErrCompacted或clientv3.ErrFutureRev，需主动重建 watch 并回退 revision - 禁用 progress notify：
clientv3.WithProgressNotify(false)，否则空事件会干扰len(wresp.Events) == 0判断
启动时先 Get 再 Watch，用 WithRev 防丢首次变更
直接 watcher.Watch(ctx, "/config") 会从当前 revision 开始监听，但 etcd 可能在你调用前就更新了 key，导致启动瞬间的变更丢失。
- 先用
clientv3.OpGet同步读一次配置：resp, _ := client.Do(ctx, clientv3.OpGet(key)) - 拿到
resp.Header.Revision，再以clientv3.WithRev(resp.Header.Revision + 1)启动 watch - 如果 key 不存在，
resp.Header.Revision是集群最新 revision，+1安全；但若集群刚启动且无写入（revision=0），需 fallback 到clientv3.WithPrefix或加重试逻辑
解析事件时直接读 Event.Kv，别重新 Get
收到 Put 类型事件后，常见错误是再发一次 clientv3.NewKV(c).Get() 拿最新值——这不仅多一次网络往返，更会破坏事件原子性：两次快速变更之间，第二次 Get 可能覆盖第一次解析结果，造成配置“回退”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 直接用
event.Kv.Value反序列化，它和该次事件的ModRevision严格对应 - 反序列化失败（如 JSON 格式错）应
log.Warn并continue，绝不能panic或阻塞 loop - 若需判断配置是否真实变化，比对
event.Kv.ModRevision而非字符串内容（避免浮点精度、字段顺序等干扰）
热更新必须原子切换，避免中间态暴露
把新配置直接赋值给全局变量或结构体字段，会导致并发读取时看到部分更新的脏数据。业务组件（如数据库连接池、HTTP handler）可能正在使用旧配置，同时又被新配置覆盖。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.RWMutex保护配置结构体：读操作走RLock，写操作用Lock+ 新建完整实例 + 替换指针 - 或用
atomic.Value存储指向配置结构体的指针，写时atomic.StorePointer，读时atomic.LoadPointer，确保读到的永远是一个完整快照 - 敏感变更（如 DB URL）建议加轻量健康检查，确认新配置可用后再切换，避免服务直接不可用
revision 断点续订和事件原子性是最容易被忽略的两个点：前者决定你是否漏掉变更，后者决定你是否读到错乱配置。这两处出问题，热更新就从“提升可用性”变成“引入不确定性”。
