Go-zookeeper的NewLock不能开箱即用，必须手动处理会话超时、Watch丢失重试、ACL权限控制三环节，否则锁不可靠。
Go-zookeeper 能直接当分布式锁底座用，但必须配合临时顺序节点 + Watch 机制，不能只靠 NewLock 就完事——它只是封装，底层逻辑还得你兜底。
为什么 NewLock 不是开箱即用的“锁服务”
go-zookeeper 的 zk.NewLock 确实提供了 Lock() 和 Unlock() 方法，但它底层依赖的是 ZooKeeper 的临时顺序节点 + Watch 机制。如果没正确处理会话超时、节点监听丢失、异常中断等情况，锁可能不释放或假释放。
-
Lock()内部会创建一个EPHEMERAL_SEQUENTIAL节点，比如/my-lock/lock-0000000001 - 它不会自动重试监听前序节点——一旦
ExistsW返回的eventchannel 关闭或阻塞，后续唤醒就失效 -
Unlock()只删自己节点，不保证前序节点已消失；若客户端崩溃，ZooKeeper 靠会话超时清理，但超时时间（默认 20–40 秒）远高于业务容忍窗口
必须手动补全的三个关键环节
生产环境里，仅调用 lock.Lock() 是危险的。以下三件事缺一不可：
- 连接必须带
time.Second*5以上超时，并用defer conn.Close()显式释放——zk.Connect返回的*zk.Conn不是线程安全的，goroutine 复用需加锁或 per-goroutine 新建 - 每次
Lock()后，必须检查返回 err 是否为zk.ErrNoNode或zk.ErrConnectionClosed，遇到这些要重建连接再重试，不能静默失败 - 业务逻辑执行中，需定期调用
conn.Exists()检查会话是否 still alive；ZooKeeper 不主动推送会话过期事件，得你自己轮询或监听zk.EventSessionExpired
zk.WorldACL(zk.PermAll) 在生产环境要禁用
示例代码里常用 zk.WorldACL(zk.PermAll)，这等于把锁路径设为全网可读写——任何能连上 ZooKeeper 的客户端都能删你节点、伪造序号、干扰锁流程。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
- 应改用最小权限 ACL：比如
[]zk.ACL{zk.ACL{Perms: zk.PermRead | zk.PermWrite, Scheme: "digest", ID: "user:base64hash"}} - ZooKeeper 集群必须开启 SASL 或 digest 认证，否则 ACL 形同虚设
- 锁根路径（如
/my-service/locks）本身要用zk.FlagPersistent创建，且只允许授权用户创建子节点
Watch 丢失后如何避免“永远等不到唤醒”
ZooKeeper 的 Watch 是一次性触发器。如果在监听前序节点时网络抖动导致事件丢失，当前客户端就会卡死——没人通知它该去抢锁了。
- 不能只依赖
ch := conn.ExistsW(prevPath)的单次 channel 接收；必须在select中加入超时分支，比如time.After(3 * time.Second) - 超时后主动调用
conn.Children("/my-lock")刷新所有子节点列表，重新判断自己是否为序号最小者 - 建议给每个锁操作设置全局 deadline，例如
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)，防止无限等待
ZooKeeper 分布式锁的可靠性不来自 API 封装，而来自你对临时顺序节点生命周期、Watch 语义、会话状态这三者的精确控制。哪怕用了 go-zookeeper，漏掉任意一环都可能让锁变成“伪互斥”。
