Redis分布式锁易出错因原子性、自动续期、安全释放未对齐；需唯一标识、Lua校验释放、独立心跳续期；etcd的CAS+Lease更可靠；数据库行锁仅适用于低频短时场景。
Redis 实现分布式锁为什么容易出错？
Redis 最常用但最易翻车，核心问题不在 SET 命令本身，而在「原子性 + 自动续期 + 安全释放」三者没对齐。比如用 SET key value EX 30 NX 能防并发争抢，但业务执行超时后，锁被自动释放，另一个节点拿到锁，而前一个还在跑——典型的「锁被别人删了」。
真正可用的方案得满足：锁必须带唯一标识（防止误删）、释放必须用 Lua 脚本校验值、续期得靠独立心跳协程（比如用 redis.NewLock 配合 WithTTL 和 WithAutoRefresh）。
- 别手写
DEL删除逻辑，必须用 Lua 确保「判断 value == 当前 token 再删」 - 过期时间不能拍脑袋设，要大于 99% 的业务执行耗时 + 网络抖动余量
-
Redlock在 Go 生态里基本没人用——它依赖多个独立 Redis 实例，实际部署复杂且收益有限
etcd 的 CompareAndSwap 为什么更可靠？
etcd 天然支持基于 Revision 和 Lease 的强一致性锁，clientv3.Txn() 可以在一个事务里完成「检查旧值 + 设置新值 + 绑定租约」，不存在中间态。租约到期自动释放，也不用担心客户端崩溃导致死锁。
Go 官方 clientv3 提供了开箱即用的 clientv3.NewMutex，底层就是封装好的 CAS + Lease 逻辑，比 Redis 手动拼更省心。
- 加锁是阻塞式调用：
mutex.Lock(ctx)，会自动重试直到成功或超时 - 解锁只需
mutex.Unlock(ctx)，内部通过 Lease ID 关联，不会误删他人锁 - 注意
ctx传的是锁操作上下文，不是业务上下文；超时应设在Lock调用前，而非整个函数
数据库行锁能当分布式锁用吗？
可以，但只适合低频、短时、强一致要求不高的场景。比如「用户每日首次签到」这种幂等性明确、执行快、冲突少的操作，用 INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或 INSERT IGNORE（MySQL）模拟锁，简单粗暴。
但它本质不是锁机制，而是利用唯一约束失败来感知竞争。一旦出现锁等待、死锁、连接中断，行为不可控，且性能随并发线性下降。
- 避免用
SELECT ... FOR UPDATE做长事务锁——网络延迟或 panic 会导致连接未释放，锁滞留数分钟 - 唯一索引字段必须是业务无歧义的键（如
user_id），不能是自增 ID 或随机字符串 - 失败后不要盲目重试，先查表确认是否真没生效，否则可能重复插入或漏处理
选型关键看这三点
不用纠结「哪个技术更高级」，盯住你的服务特征：锁持有时间、QPS 峰值、容错容忍度。
- 秒级锁 + QPS github.com/go-redsync/redsync（别自己造轮子）
- 毫秒级锁 + 强一致性必须保障 + 已有 etcd → 直接上
clientv3.NewMutex，Revision 语义天然防误删 - 单次锁几毫秒 + 每天最多几百次 + 不想引入新组件 → 数据库唯一约束兜底，但得写好幂等回查逻辑
跨语言协作时，etcd 协议比 Redis SET 指令更规范，Lua 脚本和租约 TTL 这些细节最容易在交接时漏掉——文档再全，也不如租约 ID 和 Revision 这种服务端生成的硬指标靠谱。
