redis setnx在go中锁不住并发，因未设过期时间易致死锁；需用set key value nx ex ttl原子命令，value须唯一且含pid/时间戳，释放锁必须用lua脚本校验value后删除。
redis SetNX 在 Go 里为啥锁不住并发？
因为 SETNX 只是原子写入，没配过期时间，一旦客户端崩溃或网络中断，锁就永远卡住——这不是并发控制，是死锁制造机。
Go 官方 redis 客户端（如 github.com/go-redis/redis/v9）不直接暴露 SETNX，而是推荐用 Set 的 SET 命令变体，靠 WithArgs("NX", "EX", ttl) 一次性完成「不存在才设值 + 自动过期」。
-
SET key value NX EX 30是正确姿势；分开调SETNX+EXPIRE会出竞态 - value 必须唯一（比如用 UUID 或
os.Hostname()+"-"+pid+"-"+rand），否则别的客户端能误删锁 - ttl 要明显大于业务执行耗时，但也不能太长（比如 10s 业务，设 30s 过期比设 300s 更安全）
Go 分布式锁的释放为什么总报 “DEL 不是你的锁”？
因为释放锁必须用 Lua 脚本保证「判断 value 相等 + 删除」原子性；直接 DEL key 会删掉别人刚抢到的锁。
常见错误是用 GET 判断再 DEL，中间有窗口期。正确做法是用 eval 执行一段 Lua：
立即学习“go语言免费学习笔记（深入）”；
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end在 Go 里用 client.Eval(ctx, script, []String{key}, value).Int64() 调用，返回 1 表示删除成功，0 表示不是自己的锁。
- 脚本里的
KEYS[1]和ARGV[1]对应传入的[]string{key}和value - 别手写字符串拼接 Lua，容易被注入；固定脚本内容，只变量替换参数
- 如果用的是
redigo，注意它默认不支持EVAL的批量参数，得用Do+redis.Args构造
用 redsync 或 go-redlock 库反而更难 debug？
因为它们封装了重试、多节点投票、自动续期等逻辑，出问题时你不知道是网络超时、节点不一致，还是本地 clock skew 导致 lease 判定失败。
小规模单 Redis 实例（非集群）场景下，自己写 50 行以内的锁封装更可控：
- 核心就三个方法：
Lock(ctx, key, value, ttl)、Unlock(ctx, key, value)、TryLock(ctx, key, value, ttl) - 所有操作带
ctx，超时由上层控制，别在锁内部硬写time.Sleep - 避免依赖
time.Now()做租约校验——Redis 服务端时间可能和客户端差几秒，租约到期该以 Redis 的PTTL返回为准
Redis 集群模式下 SetNX 失效的真相
因为 SETNX 是单 key 命令，而 Redis Cluster 会把不同 key 分到不同 slot，如果 key 被 hash 到多个节点，SETNX 操作无法跨节点原子执行。
此时不能靠单个 SET 命令，得用 Redlock 算法：依次向 N/2+1 个 master 节点尝试加锁，总耗时不超过锁 ttl 的一半，才算获取成功。
- go-redlock 默认用 3 个节点，但你要确认这些节点确实是独立 master，不是 replica
- 集群环境下，
key最好带{xxx}tag（如lock:{order_123}）强制落到同一 slot，但这只解决单 key 场景，不等于 Redlock - 真正高可用要求下，别省事——要么接受 Redlock 的复杂性，要么换用 etcd（支持 Lease + CompareAndDelete 原子语义）
最常被忽略的一点：锁的 value 不只是防误删，更是调试线索。线上出问题时，GET lock:xxx 返回的 value 能立刻告诉你谁持锁、大概什么时候申请的——这个字段别用固定字符串，至少带上 pid 和毫秒时间戳。