zk.connect 不 panic 的关键是：传全地址列表、设 5 秒以上超时、连接后立即用 state() 检查是否为 stateconnected，不能仅依赖 err == nil。
zk.Connect 怎么连才不 panic？
连接失败是 Go-Zookeeper 最常见的卡点，zk.Connect 一调就 panic，不是地址错，就是超时太短。它不返回连接状态码，而是直接返回 error，但很多人忽略检查就往下走。
- 超时时间别写
time.Second—— 本地单机可能够，但集群网络抖动或 DNS 解析慢时，1 秒根本不够，建议从5 * time.Second起手 - 地址列表必须写全，比如
[]string{"zoo1:2181", "zoo2:2181", "zoo3:2181"}，不能只写一个；ZooKeeper 客户端靠它做故障自动切换，少一个就可能连不上 - 连接后立刻调
c.State()确认状态，别只信 err == nil —— 有时会返回StateConnecting，这时还没真正 ready，得等事件通知或轮询
示例：conn, _, err := zk.Connect([]string{"127.0.0.1:2181"}, 5*time.Second)，紧接着加 if c.State() != zk.StateConnected { ... }。
Create 的 flags 参数为什么总创建失败？
Create 的 flags 是 int32，但它的取值不是随便填数字，而是组合位运算结果，填错就静默失败或报 ZBADARGUMENTS 错误。
-
0：持久节点（最常用） -
zk.FlagEphemeral：临时节点，session 断开自动删 —— 注意：不能有子节点 -
zk.FlagSequence：顺序节点，路径末尾自动加 10 位数字，比如/task-→/task-0000000001 - 组合用
|，比如临时顺序节点：zk.FlagEphemeral | zk.FlagSequence，不能写成3（虽然值碰巧对，但可读性差、易出错）
常见坑：用 FlagEphemeral 创建节点后，没维持 session 心跳（比如没起后台 goroutine keep-alive），连接一断，节点就消失，查不到还以为代码没执行。
Set/Delete 为什么老报 “Bad version”？
Set 和 Delete 都要传 version，这是 ZooKeeper 的乐观锁机制。填错版本号不是忽略，而是直接拒绝，错误信息通常是 ZBADVERSION。
- 查节点时用
Get，它返回的*Stat里有Version字段，这才是当前真实版本 - 填
-1表示跳过校验 —— 仅限开发调试，线上慎用，否则可能覆盖别人刚写入的数据 - 批量操作（Multi）里不能混用
-1，必须显式传每个节点当前版本，否则整个事务回滚
典型场景：两个服务同时监听配置节点，都拿到旧数据改完再 Set，后写的那个如果没重读 version，必然失败 —— 这不是 bug，是设计用来防并发冲突的。
Watch 机制为什么事件只触发一次？
Get 自带 watch（如 GetW），但 ZooKeeper 的 watch 是**一次性**的：触发后自动失效，不续订就不会再通知。
- 要用
GetW获取数据和事件通道chan zk.Event，然后在 goroutine 里for range消费 - 每次收到事件后，必须立刻再调一次
GetW重新注册，否则下次变更收不到 - 别在主线程里同步等待事件 —— 会阻塞，而且没处理完前新事件会丢（channel 默认 buffer=1）
最容易被忽略的是：watch 不保证顺序，也不保证送达。网络分区或客户端 GC 延迟时，事件可能晚到甚至丢失，业务逻辑得有兜底（比如定期轮询 + etag 或 zxid 校验）。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
