启用强一致性读必需同时使用 clientv3.withrequireleader() 和 clientv3.withserializable(false)，前者强制请求路由至 leader，后者禁用可串行化以启用线性一致读；默认 get() 虽走 leader 但未禁用可串行化时仍可能因 follower 缓存或 revision 滞后返回旧值。
clientv3.WithRequireLeader() 和 clientv3.WithSerializable(false) 是启用强一致性读的必需组合，缺一不可。默认 Get() 虽走 leader，但若未显式禁用可串行化，仍可能因 follower 缓存或网络延迟返回旧值。
为什么默认 Get 不等于强一致
etcd v3 的 Get() 默认行为是线性一致（linearizable），但它依赖底层 Raft 状态同步及时性。实际中常见问题包括：
- 客户端连接的是 follower 节点，且该节点尚未同步最新 commit —— 此时即使没加
WithSerializable()，也可能读到 stale 数据 - 集群网络分区后恢复初期，部分节点 revision 滞后，
Get()无显式约束时可能路由到滞后节点 - gRPC 连接复用导致请求被负载均衡到非 leader 节点，而 clientv3 不自动重试 leader
所以必须用 WithRequireLeader() 强制路由，再用 WithSerializable(false) 关闭可串行化读（注意：false 表示“不使用可串行化”，即启用更强的 linearizable 模式）。
Put/Txn 必须绑定租约并校验 version
元数据写入不是简单 Put() 就完事。例如创建文件或重命名目录，若并发冲突或中间失败，会导致状态不一致。
- 所有写操作必须带
clientv3.WithLease(leaseID)，否则节点宕机后元数据残留 - rename 或 move 操作必须用
clientv3.Txn()包裹：先If检查旧 key 存在且Version == expected，再Then删除旧 key + 写新 key - 避免直接
Delete()后Put()—— 中间窗口期会让元数据“消失” - Watch 目录前缀时，路径末尾不要多加斜杠：
/meta/user/和/meta/user是两个不同前缀，WithPrefix()不会匹配后者
Watch 前缀变更必须持续消费 channel
clientv3.Watch() 返回的是一个流式 WatchChan，缓冲区默认只有 100 条。一旦没及时读取，事件就丢弃，且不会重发、不会告警。
- 必须起独立 goroutine 持续读取：
go func() { for wr := range watchChan { /* 处理 */ } }() - 首次 watch 建议用
clientv3.WithLastRev()获取当前 revision，再从rev + 1开始监听，避免漏掉刚写入的数据 - 遇到
ErrCompacted说明历史 revision 被压缩，需重新Get()当前值 +WithLastRev()重建 watch - watch 的 context 被 cancel 后，channel 会关闭，不能复用，必须新建
连接配置稍有偏差就会静默失败
clientv3.New() 返回 nil error 并不代表可用。很多“连不上 etcd”的问题其实发生在第一次 Get() 或 Put() 时卡住或报 context.DeadlineExceeded。
-
Endpoints必须带协议和端口："http://127.0.0.1:2379"，写成"localhost:2379"会降级为 http，若服务端只开 https 就彻底失败 - 本地开发关 TLS 时，必须加
grpc.WithInsecure()；生产启 TLS 时，tls.Config缺 CA、证书、密钥或ServerName都会握手失败 -
DialTimeout只管 TCP 连接，不管 TLS 握手和 gRPC 初始化——业务调用务必单独设context.WithTimeout() -
AutoSyncInterval建议设为 30s，避免集群成员变更后 client 长时间路由到下线节点
强一致性不是开关一开就万事大吉，它依赖每个环节都按 Raft 语义严格执行：租约绑定、事务封装、watch 持续消费、连接参数精确匹配。最容易被忽略的是 WithSerializable(false) 的语义反转，以及 watch channel 不消费导致的静默丢事件。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
