etcd watch 通过 revision 断点续订保障不丢变更：启动前先 get 全量获取当前 revision，watch 时传 start_revision；响应中 response.created 为 false 才是增量事件；需显式处理 errcompacted 等错误，避免依赖 sdk 自动重连。
etcd watch 机制怎么保证配置变更不丢
watch 不是“监听一次就完事”，它本质是长连接流式订阅，但网络抖动或客户端重启会导致事件丢失。关键在于 etcd 的 watch 支持 revision 断点续订——你得自己存上次收到的 kv.mod_revision，下次 watch 时带上 start_revision 参数。
常见错误现象：watch 启动后没收到首次变更，或者服务重启后漏掉中间几次更新。
- 首次启动必须先
get全量配置，拿到当前header.revision，再用这个 revision 启动 watch - 每次收到响应后，检查
response.created字段：为true表示是新建立的 watch 流，不包含历史事件；为false才说明是增量事件流 - 不要依赖 client SDK 默认的自动重连逻辑（比如 go-etcd 的
WithRequireLeader不等于断线续传），必须显式处理ErrCompacted和ErrFutureRev
如何避免 /config/db/host 这类路径变更引发热更新错乱
etcd 是纯 KV 存储，没有目录监听能力。所谓“监听目录”，其实是 watch 带前缀的 key（如 prefix="/config/"），但前缀匹配不区分层级语义，/config/db/host 和 /config/db/hostname 都会被同一个 watch 捕获。
使用场景：微服务按模块组织配置，比如 /config/user-service/timeout、/config/order-service/timeout，但又不想每个服务写死完整路径。
- 约定 key 命名规则，比如强制末尾加
/value或:raw标识叶子节点（如/config/db/host:value），watch 时只匹配该后缀 - 服务启动时
get全量 prefix，构建本地 key 映射表；watch 到变更后，只对表中已存在的 key 做更新，忽略新增或删除的 key（除非你明确支持动态加载） - 避免用
get+withPrefix拉全量做 diff——小规模可用，但 key 数过千后延迟明显，且无事务性
Go 客户端里 WatchChan 和 Watcher 的生命周期怎么管
clientv3.Watcher 是复用型对象，但 WatchChan 是单次消费通道。很多人误以为一个 Watcher 对应一个长期有效的 channel，结果发现 channel 关闭后收不到后续事件。
性能影响：频繁新建 Watcher 会触发 etcd server 端新建 stream，增加 leader 负担；而长期持有未关闭的 Watcher 又可能累积 goroutine 泄漏。
- 一个服务实例只需一个全局
clientv3.Watcher实例，复用它调用多次Watch方法 - 每次
Watch返回的WatchChan必须被持续读取，否则缓冲区满（默认 100 条）会导致 server 端阻塞甚至断连 - channel 关闭时（如收到
ctx.Done()），要主动调用cancel()函数清理底层 stream，不能只关 channel - 别在
for range 里直接处理业务逻辑——出错 panic 会导致整个 watch 流中断，建议用 <code>select+case wresp := 包一层 recover
配置值反序列化失败导致热更新静默失败怎么办
etcd 存的是 raw bytes，get 或 watch 回来的内容不会自动转成 struct。很多实现把反序列化放在 watch 回调里，一旦 JSON 解析失败（比如字段类型变了、多了非法字符），整个更新流程就卡住，且无日志提示。
容易踩的坑：用 json.Unmarshal 直接解到结构体指针，但没检查 error，或把 error 日志打在 debug 级别，线上根本看不到。
- 所有反序列化必须有明确 error 分支，且至少 warn 级别输出原始 bytes（截取前 200 字符）、key 路径、当前 revision
- 推荐先用
json.RawMessage接收，验证格式后再解析，避免因某个 key 解析失败影响其他 key 更新 - 如果配置项允许部分失效，更新逻辑里要做 key 粒度的 try/catch，而不是整个配置块原子回滚——热更新本就不该强求全量一致
- 上线前用
etcdctl get --prefix /config/ | jq -r 'keys[]'检查 key 命名是否统一，避免空格、不可见字符等导致 decode 失败
最麻烦的不是 watch 不工作，而是它“看起来在工作”——事件来了、channel 收到了、也进了回调，但反序列化一崩，后续逻辑全跳过，连个 log 都没有。这种静默失败在线上最难排查。
