不能直接用 Pod 名当锁 key，因为 Pod 名不稳定且不支持原子操作；应使用 Lease 对象通过 resourceVersion 实现带超时的分布式锁，锁 key 需为稳定业务标识。
为什么不能直接用 Pod 名当锁 key
Pod 名称在 Kubernetes 中不是稳定的标识符——重启、滚动更新、节点故障都会导致新 Pod 生成，旧 Pod 被删除，名称可能复用（尤其用了 generateName）。更关键的是：Pod 对象本身不支持原子性加锁操作，你无法靠 Update 或 Patch 实现“检查并设置”的语义。直接拿 pod.Name 当分布式锁 key，等于把锁挂在沙子上。
真正可行的路径只有一条：用 Kubernetes 原生支持乐观并发控制（OCC）的对象，比如 ConfigMap 或 Lease（推荐），通过 resourceVersion 做条件更新来模拟互斥。
用 Lease 对象实现锁：最小、最轻量的方案
Lease 是 K8s v1.12+ 引入的专用协调对象，专为心跳与租约设计，比 ConfigMap 更轻、更新更高效，且天然带 acquireTime 和 renewTime 字段，适合做带超时的锁。Go 客户端操作它，核心就是「创建 + 条件更新」两步。
- 锁 key 应该是稳定标识，比如
"lock-<em>your-app-name</em>-<em>task-id</em>"，**不要用pod.Name**；可从环境变量或标签中提取业务维度 ID - 加锁时调用
LeasesClient.Create()，若返回409 Conflict（表示已存在），说明锁被占；否则成功 - 续锁必须用
LeasesClient.Update()并带上当前resourceVersion，失败就说明锁已丢失，需重新竞争 - 锁持有者应定期 renew（建议间隔 ≤ 锁 TTL 的 1/3），TTL 推荐设为 15–30 秒，避免僵死锁
// 示例：尝试获取锁
lease := &coordinationv1.Lease{
ObjectMeta: metav1.ObjectMeta{
Name: "lock-myjob-abc123",
Namespace: "default",
},
Spec: coordinationv1.LeaseSpec{
HolderIdentity: podName, // 这里才放当前 Pod 名，仅作身份标记
LeaseDurationSeconds: ptr.To[int32](30),
AcquireTime: &metav1.Time{Time: time.Now()},
},
}
_, err := client.Leases(namespace).Create(ctx, lease, metav1.CreateOptions{})常见错误现象和踩坑点
实际跑起来最容易卡在三个地方：
立即学习“go语言免费学习笔记（深入）”；
- RBAC 权限不足：ServiceAccount 缺少
leases资源的create/update/get权限，报错是"leases.coordination.k8s.io is forbidden" - 忘记清理残留 Lease：Pod 意外退出没释放锁，后续所有竞争者都卡在
409；必须配合Lease的 TTL 自动过期，**不能依赖主动 delete** - 用错了命名空间：锁作用域是 namespace 级，跨 namespace 的 Pod 无法感知同一把锁；确保所有参与方操作的是同一个
Namespace - HolderIdentity 写成固定字符串（如
"worker"）：多个 Pod 会互相覆盖，失去身份区分能力；必须填唯一值，比如os.Getenv("HOSTNAME")
要不要自己封装成库？先看这三点
直接调用 client-go 的 Leases API 已足够轻量，不建议过早封装通用锁库，除非你同时满足：
- 有多个服务共用同一套锁逻辑，且锁策略（TTL、重试、fallback）高度一致
- 团队内已统一使用结构化日志，并能对
Lease更新失败打 trace（比如记录resourceVersion不匹配次数） - 明确需要支持「公平队列」或「读写锁」语义——原生 Lease 只提供独占写锁，复杂语义得自己叠加 etcd 或 Redis
绝大多数场景下，一个带 retry loop 的 tryAcquireLease() 函数 + 清晰的 error 判断，比抽象一层“LockManager”更可靠、更容易 debug。
