不能用 syscall.flock 做分布式文件锁，因其是内核级建议锁，仅在同一文件系统内有效，跨机器挂载（如 nfs、cephfs）时会静默失效，缺乏跨节点同步机制，无法满足多节点、多 pod 场景下的全局互斥需求。
sync.Mutex 或 syscall.Flock 无法解决分布式文件锁问题——前者只在单进程内生效，后者仅限同一台机器的进程间协作。真正在多节点、多 Pod 场景下保护共享文件（比如 NFS 挂载目录、对象存储前缀、K8s 共享卷），必须依赖外部协调服务做全局互斥。
为什么不能用 syscall.Flock 做分布式文件锁
syscall.Flock 是内核级建议锁，只对同一文件系统上的进程可见；跨机器挂载（如 NFSv3/v4、CephFS、EFS）时，Flock 调用可能静默失败或不生效，且无跨节点同步机制。常见错误现象包括：
- 两个 Pod 同时拿到
LOCK_EX成功，写入冲突 - 一个 Pod 持锁崩溃，锁未释放，其他节点永远阻塞
- 挂载点配置差异（如 NFS
noac未开）导致锁状态不同步
这不是 Go 实现的问题，而是 POSIX 文件锁协议本身不支持分布式语义。
Redis + Lua 是最轻量可行的方案
适用于 K8s Job 处理共享路径、定时任务独占写入等场景，核心是把“文件路径”映射为 Redis key，用原子操作控制所有权：
- 加锁用
SET /locks/ns1/job-a/file:///data/inbox EX 60 NX，value 设为 UUID，避免误删 - 解锁必须走 Lua 脚本：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end - 业务超时风险高？启动独立 goroutine 每 20 秒调
EXPIRE续期（同样需 Lua 校验 value） - 不要用
SETNX+EXPIRE两步——网络中断会导致 key 存在但无过期时间
etcd 更适合强一致性文件锁
当你的文件操作涉及关键数据（如财务对账、审计日志归档），且能接受稍高延迟，etcd 的 Raft 日志保证比 Redis 主从更可靠：
- 锁 key 格式固定为
/locks/{namespace}/{job-name}/{file-path}，防 namespace 冲突 - 先
client.Grant(ctx, 30)获取 lease ID，再client.Put(ctx, key, uuid, clientv3.WithLease(leaseID)) - 抢锁必须用
client.Txn(ctx).If(clientv3.Compare(clientv3.Version(key), "=", 0)).Then(clientv3.OpPut(...))原子判断 - 续期别依赖
KeepAlive流——它可能因连接抖动断开；应每 10 秒调一次client.KeepAliveOnce(ctx, leaseID)，失败立即Revoke
锁 key 设计和清理最容易被忽略
没设计好 key 结构或没处理异常退出，会导致锁堆积、GC 漏洞、跨租户污染：
- 绝对不用全局前缀如
/locks/xxx，必须带{namespace}和{resource}两级隔离 - etcd 中过期锁不会自动删除——lease 过期后 key 仍存在，只是 value 变为空；需定期扫描
client.Get(ctx, prefix, clientv3.WithPrefix())清理 - Redis 锁靠 TTL 自动释放，但业务 panic 时若没调
Unlock()，得靠 watchdog goroutine 主动检测并释放 - 别在
defer里放解锁逻辑——如果加锁失败，defer仍会执行，可能删掉别人刚设的锁
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
