Go-zookeeper分布式锁强一致性的基础是临时顺序节点：临时节点保障断连自动清理，顺序节点提供FIFO排队能力，二者缺一不可；必须严格按创建节点→获取并排序子节点→比对最小序号三步执行，且Watch仅监听前驱节点，释放时须用自身创建的精确路径。
Go-zookeeper 实现的分布式锁天然具备强一致性，但必须严格按 ZK 的节点生命周期和监听逻辑编码，否则容易卡死或假释放。
为什么 go-zookeeper/zk 的临时顺序节点是强一致基础
ZooKeeper 的 Ephemeral + Sequential 节点组合，是强一致锁的物理前提。临时节点绑定 Session 生命周期，客户端断连后节点自动消失；顺序节点名自带递增序号（如 lock-0000000001），天然构成 FIFO 队列。这二者缺一不可——漏掉 zk.Ephemeral 标志，就失去自动清理能力；不依赖 zk.Sequential，就无法判断前驱节点，也就没法做精准 Watch。
常见错误现象：
- 手动指定节点名（如
/lock/client1），导致多个客户端写入同一路径，覆盖失败或竞争异常 - 创建节点时没传
zk.Ephemeral | zk.Sequential，而是只用0或zk.Permanent，锁无法自动释放 - 连接未设置合理 Session timeout（如低于 5s），网络抖动就频繁触发节点误删
acquireLock 必须包含三步原子动作：创建节点 → 获取子节点列表 → 判断是否最小序号
不能跳过“获取所有子节点并排序”这一步。ZK 不保证你创建的节点就是当前最小序号——可能有其他客户端同时创建，你的节点序号未必是第一。所以必须：
立即学习“go语言免费学习笔记（深入）”；
- 调用
conn.Children(lockPath)拿到全部子节点名（如[]string{"lock-0000000001", "lock-0000000002", "lock-0000000003"}） - 对节点名做字典序排序（注意不是数值排序，ZK 序号固定 10 位，
sort.Strings()即可） - 取排序后第一个节点，和自己刚创建的节点比对；相等则持有锁，否则监听前一个节点
示例关键逻辑片段：
node, _, err := conn.Create(lockPath+"/lock-", []byte{}, zk.Ephemeral|zk.Sequential, zk.WorldACL(zk.PermAll))
if err != nil {
return "", err
}
// node 形如 "/my-distributed-lock/lock-0000000005"
children, _, err := conn.Children(lockPath)
if err != nil {
return "", err
}
sort.Strings(children)
if children[0] == filepath.Base(node) {
return node, nil // 拿到锁
}
Watch 机制必须只监听前驱节点，且需重试处理 zk.ErrNoNode
每个客户端只应监听比自己序号小 1 的那个节点（如你的是 lock-0000000005，就监听 lock-0000000004）。这是避免羊群效应的核心——ZK 不会广播所有节点删除事件，只通知明确注册了 Watch 的客户端。
容易踩的坑：
- 监听路径写错，比如监听
lockPath根目录，导致所有客户端被唤醒，争抢变串行 - Watch 回调里没重新执行 acquire 逻辑，而是直接返回，造成锁永远拿不到
- 收到
zk.ErrNoNode（前驱节点已被删但 Watch 尚未触发）时没 fallback 到主动轮询检查，导致假阻塞
正确做法是在 Watch 回调中触发一次新的 acquireLock 调用，而不是仅 sleep 后重试。
释放锁只需 conn.Delete(node, -1)，但必须确保 node 是自己创建的
释放操作本身极简，但前提是 node 路径必须 100% 来自自己上一步 Create 返回值。不能拼接、不能缓存、不能跨 goroutine 复用。因为：
- ZK 的
Delete是幂等但非授权操作：只要路径存在且你有权限，就能删——哪怕那是别人建的 - 若误删他人节点，会直接破坏 FIFO 队列，后续客户端可能跳过排队直接拿到锁
- 没有类似 Redis 的 Lua 原子校验（
GET + DEL），所以必须靠代码逻辑隔离
建议把 node 封装进锁结构体，和业务逻辑绑定生命周期，避免泄露或误用。
真正麻烦的从来不是加锁或解锁那几行代码，而是节点命名规则、Watch 目标选择、以及 Session 过期与网络分区之间的边界条件处理——这些地方写错一点，锁就从“强一致”退化成“偶尔可用”。
