etcd Watch 收不到通知主因是上下文取消或连接断开未重连；需持续读取WatchChan、检查chan关闭、用WithRev避免漏事件、幂等处理重复变更。
etcd Watch 为什么总收不到变更通知
Watch 不触发，大概率是 clientv3.Watch 的上下文提前取消或连接断开没重连。etcd 的 watch 是长连接 + 流式响应，不是轮询，一旦 ctx.Done() 就彻底终止，也不会自动恢复。
- 确保传入
context.WithCancel或context.Background()，别用context.TODO()或已过期的 ctx - watch 返回的
clientv3.WatchChan是只读 channel，必须在 for-range 中持续读取，否则缓冲区满后会阻塞后续事件（默认缓冲 100 条） - 连接异常时，
WatchChan会关闭，但不会报错——你需要检查ok == false并主动重建 watch - 如果用
clientv3.WithPrefix()监听目录，注意 key 必须带前缀且结尾不加/（比如监听/config/，写入 key 应为/config/db_host，不是/config//db_host）
如何安全地读取 etcd 配置并支持热更新
直接每次读 clientv3.Get 效率低、无变更感知；全靠 watch 自己维护内存状态又容易丢事件。折中做法是：watch 启动时先 Get 一次做初始化，再持续消费 watch 事件更新本地 map。
- 初始化阶段用
clientv3.WithSerializable()降低读取延迟，但注意它不保证线性一致性 - watch 时加上
clientv3.WithRev(lastRev + 1)可避免漏掉初始化 Get 和 watch 建立之间的中间变更（需保存上次 Get 的resp.Header.Revision） - 更新本地配置时，建议用
sync.Map或加读写锁的普通 map，避免并发读写 panic - 不要在 watch 循环里做耗时操作（如 HTTP 请求、DB 写入），否则会卡住 channel 接收，导致事件堆积或丢失
Watch 多个 key 时要不要合并成一个请求
要。etcd server 对单个 watch 请求可同时监听多个 key 或 prefix，比开多个 goroutine + 多个 watch 节省连接和资源，也更容易统一错误处理。
- 用
clientv3.WithPrefix()替代多个clientv3.WithFromKey()单 key watch - 如果必须监听离散 key（比如
/a、/c、/x/y），只能起多个 watch——但每个都要独立处理chan关闭和重连逻辑 - server 端对单个 watch 的 key 数量没有硬限制，但 revision 比较和事件分发有开销，上百个 key 建议按业务域拆分
- 注意
clientv3.WatchOption是可变参数，多个 option 直接拼在一起传，比如：clientv3.WithPrefix(), clientv3.WithRev(100)
Watch 重启后如何避免重复处理同一变更
etcd 不保证事件“恰好一次”，网络抖动或 client 重建 watch 时可能收到重复的 Put 事件。关键不是防重，而是让配置更新本身幂等。
立即学习“go语言免费学习笔记（深入）”；
- 每次 watch 事件都携带
kv.ModRevision，可存为 lastAppliedRev，跳过已处理过的 revision - 但要注意：revision 是集群级单调递增，不同 key 的 revision 不可直接比较大小来判重；更稳妥的是对每个 key 维护自己的 lastSeenRev
- 真正保险的做法是把配置值本身做结构化校验（比如 JSON 字符串 diff），或者用 atomic.Value + 指针比较是否真有变化
- 别依赖 etcd 的
PrevKV选项来做“旧值对比”——它只在事务中可靠，普通 watch 的 PrevKV 是 best-effort，可能为空
Watch 的断连恢复、revision 跳变、事件乱序，这些都不是 bug，是分布式系统常态。写的时候就要默认“事件可能重复、可能延迟、可能丢失”，靠客户端逻辑兜底，而不是指望服务端完美投递。
