etcd clientv3 keepalive 必须用独立 goroutine 持续消费响应 channel，仅校验 resp.id 有效性并处理 nil（触发重连）；watch 必须带 withrev 续订以防丢事件；服务状态需显式字段（如 status="ready"）而非仅依赖 key 存在；本地缓存应增量更新，避免抖动；网络分区时须同时校验 lease 有效性和 status 状态。
etcd clientv3 的 KeepAlive 必须用 goroutine 持续读取，不能只调用一次
很多 Go 服务注册后很快就掉线，不是 lease 过期，而是 client.KeepAlive 返回的 chan *clientv3.LeaseKeepAliveResponse 没被消费。etcd 客户端在 stream 关闭前会缓冲少量响应，但一旦缓冲满、或 goroutine 阻塞（比如日志写磁盘卡住），stream 就会被服务端强制关闭，后续心跳失效。
正确做法是启动独立 goroutine 循环读 channel，并仅做最小化处理：
- 只检查
resp.ID是否有效，不解析resp.TTL或做其他 I/O - 遇到
nil响应（表示 stream 关闭）时，立即退出 goroutine 并触发重连逻辑 - 不要在该 goroutine 中调用
client.Get、client.Put等阻塞操作
Watch 变更必须带 WithRev 续订，否则丢事件
客户端 Watch 断开后直接重新 client.Watch(ctx, prefix, clientv3.WithPrefix())，大概率漏掉断连期间的变更。etcd 不保证事件不丢失，除非你明确告诉它从哪次 revision 开始补。
实操要点：
- 首次 Watch 不传
WithRev，拿到resp.Header.Revision后存为本地 lastRev - 断连重试时，用
client.Watch(ctx, prefix, clientv3.WithPrefix(), clientv3.WithRev(lastRev+1)) - 若收到
rpc error: code = OutOfRange，说明 revision 被 compact，此时必须全量client.Get(ctx, prefix, clientv3.WithPrefix())并重置 lastRev
服务实例状态不能只靠 key 存在与否判断
刚启动的服务可能 DB 连接未就绪、缓存未预热，但 etcd 里 key 已存在，客户端立刻把它加入负载列表，导致请求失败。单纯依赖 TTL 过期兜底太慢（通常设 30s），来不及拦截首批流量。
必须引入显式状态字段：
- 注册 value 是 JSON，含
status字段（值为"starting"/"ready"/"failed"） - 服务自检通过后，用
client.Put更新该 key，只把status == "ready"的实例纳入可用列表 - Watch 到变更后，先查
client.TimeToLive确认 lease 有效，再反序列化 status 字段
本地缓存更新不能依赖单次 Watch 事件
Watch 返回的 resp.Events 可能为空（比如心跳保活 ping），也可能一次包含多个 PUT/DELETE。如果每次事件都重建整个连接池或刷新全部实例，会引发抖动和资源泄漏。
安全做法是维护一个内存 map：
- key 是实例唯一标识（如
ip:port），value 是结构体含地址、lastHeartbeat、status - 仅当
ev.Type == clientv3.EventTypePut且新 value 中status变为"ready"，或ev.Type == clientv3.EventTypeDelete，才触发对应实例的连接增删 - 相同地址的重复 PUT（比如心跳刷新）忽略，避免反复拨号
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
