分布式环境下“文件锁”不可靠，必须用etcd或redis等协调服务实现；os.openfile+o_excl和flock在k8s多pod或nfs场景下均失效，真正可行的是etcd cas+lease方案。
直接说结论：在分布式环境下，“文件锁”这个说法本身就是个陷阱——你没法靠单个文件系统实现跨机器互斥，必须换用 etcd 或 Redis 这类协调服务。所谓“分布式文件锁”，本质是“用分布式协调器模拟文件锁语义”。
为什么 os.OpenFile + O_EXCL 在集群里根本不可靠
很多人一上来就想复用本地开发经验：用 os.OpenFile(path, os.O_CREATE|os.O_EXCL, 0644) 创建锁文件。这在单机上能 work，放到 K8s 多 Pod 或 NFS 共享存储下立刻崩：
- NFS 不保证
O_EXCL原子性，两个 Pod 可能同时创建成功 - 锁文件被误删或进程崩溃后残留，没人清理 → 锁永远卡住
- 没有持有者标识，A 进程挂了，B 进程无法安全接管
- 无超时机制，锁一旦被占，其他节点只能干等
这些不是边缘 case，而是部署到生产环境第一天就会撞上的真实问题。
flock 在分布式场景下完全失效
flock 看似优雅（fd 关闭自动释放、内核级保障），但它只作用于**同一个文件系统上的同一 inode**。K8s 中每个 Pod 的容器 rootfs 是隔离的，即使挂载了同一 NFS 路径，flock 也无法跨进程生效——因为每个容器看到的是各自 mount namespace 下的独立 fd 视图。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
更关键的是：flock 是建议性锁，不强制约束；它也不跨网络、不带租约、不支持 watch，跟“分布式”三个字毫无关系。
所以别在 YAML 里挂共享卷然后幻想 flock 能协调多个 Pod —— 它连本机不同 mount namespace 的进程都管不了。
真正可行的方案只有 etcd CAS + lease
如果你的集群已跑在 K8s 上，etcd 就是现成的、高可用的协调后端。不用另起 Redis，也不用维护 ZooKeeper。重点不是“怎么写代码”，而是“怎么避开 clientv3 的默认坑”：
- 锁 key 必须带命名空间隔离，例如
/locks/{namespace}/{name}/file:///data/inbox，绝不能用全局/locks/xxx - 每次
TryLock必须生成新ownerID（如uuid.NewString()），写入时绑定显式leaseID：client.Put(ctx, key, ownerID, clientv3.WithLease(leaseID)) - 校验必须走
clientv3.Txn()原子事务：Compare当前 value 是否为空 或 等于自己的ownerID，Then才算抢锁成功 - 续约不能依赖
KeepAlive流式连接（易断、难监控），推荐用独立 goroutine 每 5 秒调一次client.KeepAliveOnce(ctx, leaseID)，失败则主动Revoke - 解锁前必须先
Get当前值比对，匹配才Revoke对应 lease —— 否则别人续租成功后你一撤租，锁就丢了
最常被忽略的一点：etcd 的 context.WithTimeout 会直接 cancel 请求，导致 lease 续约中断却没触发 cleanup。实际中应该用带重试的短 timeout + 显式错误分支处理，而不是把所有逻辑塞进一个 context 里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
