Consul 的 Lock 方法返回一个 channel，需显式检查该 channel 是否为 nil 来判断锁是否成功获取；仅依赖错误值（err）无法检测锁竞争失败，这是常见误用点。
consul 的分布式锁机制要求开发者主动检查 `lock()` 方法返回的 channel 是否为 nil，而非仅依赖 error 判断——因为当锁已被占用且启用了 `locktryonce: true` 时，`lock()` 会立即返回 `(nil, nil)`，表示“未获取到锁、也未发生错误”。这是 consul 客户端设计的关键语义，也是本测试用例始终不失败的根本原因。
Consul 的 api.Lock 实现基于会话（Session）与 KV 原子操作，其 Lock() 方法采用非阻塞或有限等待策略时，成功获取锁才返回有效 channel，否则返回 nil（且 err == nil）。因此，正确的锁获取校验逻辑必须包含对返回 channel 的显式判空：
// ✅ 正确：检查 channel 是否为 nil
ch, err := lock.Lock(nil)
if ch == nil {
t.Fatal("lock was not acquired — another client holds it")
}
if err != nil {
t.Fatalf("lock acquisition failed with error: %v", err)
}
// 锁已获取，可安全使用 ch 接收释放通知此外，还需注意以下关键实践要点：
-
每个客户端必须使用独立 Session：示例中为
firstLock和secondLock分别指定唯一SessionName（推荐使用 UUID），否则因共享 Session 导致锁所有权混淆，甚至出现“伪重入”行为； -
LockTryOnce: true+LockWaitTime仅控制等待行为，不改变返回语义：即使设置超时，只要锁不可用，Lock()仍返回(nil, nil)，而非非 nil error； -
务必调用
Unlock()或确保 Session 自动过期：持有锁的 client 应显式释放（如defer lock.Unlock()），否则锁将依赖 Session TTL 自动失效，可能引发长时间阻塞。
完整修复后的测试逻辑强调两点核心校验：
- 第一次
Lock()必须返回非 nil channel； - 第二次
Lock()在锁已被持有时，必须返回nilchannel（且err == nil），此时即应判定为竞争失败。
遵循此模式，才能真正保障 Consul 分布式锁的互斥语义，避免多实例并发写入、重复任务执行等典型分布式竞态问题。
