redis setnx不能直接当分布式锁用，因其无法原子性设置过期时间，易导致死锁；正确做法是使用set key value ex seconds nx原子命令，并配合lua脚本校验value后删除锁。
Redis SETNX 命令为什么不能直接当分布式锁用
因为 SETNX 只能设值，没法同时设置过期时间，导致锁可能永远不释放。比如进程写完 SETNX key 1 就崩溃了，后续谁也拿不到锁。
正确做法是用 Redis 的原子命令 SET key value EX seconds NX，它把“判断不存在 + 设值 + 过期”三步压成一步。Go 客户端（如 github.com/go-redis/redis/v9）对应的是 SetNX 方法，但必须显式传 WithContext 和 redis.SetArgs{Expire: time.Second * 30}，否则还是没过期逻辑。
- 别用
SETNX+EXPIRE两步：中间崩溃就死锁 - 过期时间不能拍脑袋定：要大于业务最大执行时间，再加一点缓冲（比如 1.5 倍），否则锁自动释放后别的协程进来，原协程还在删锁，就误删了
- 客户端连接中断时，
context.WithTimeout必须包住整个SetNX调用，不然网络卡住会 hang 住 goroutine
Go 里怎么安全地释放 Redis 分布式锁
释放锁不是简单 DEL key，得确保只删自己设的锁——否则 A 拿到锁，B 超时后自己又抢到，A 结束时一删，就把 B 的锁干掉了。
通用解法是：设锁时用唯一值（比如 UUID 或随机字符串）作为 value；删锁时用 Lua 脚本比对 value 再删。Go 客户端调用 Eval 执行这段脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
注意：Eval 的 keys 参数必须是 []string{"my_lock_key"}，args 是 []interface{}{lockValue}，顺序错或类型错都会返回 0 且不报错。
- value 不能用时间戳或 PID：可能重复；推荐用
uuid.NewString() - 别在
defer里无条件删锁：万一加锁失败，defer还是会跑，删一个根本不存在的 key 倒没事，但掩盖了加锁失败的问题 - Lua 脚本必须用
Eval，不能拆成 GET + DEL：中间可能被别的 client 插入
Redlock 算法在 Go 项目里要不要上
大多数业务不需要 Redlock。它解决的是“单 Redis 实例故障导致锁失效”的问题，但代价是性能下降、实现复杂、且实际场景中多数锁冲突发生在同一实例内。
如果你用的是云 Redis（如阿里云、AWS Elasticache），背后已经是主从+哨兵/集群模式，单点故障概率极低；真要高可用，优先做 Redis 连接池健康检查 + 自动重连，而不是堆 Redlock。
- Redlock 要求向 ≥3 个独立 Redis 实例发请求，耗时翻倍，对延迟敏感的服务不友好
-
go-redsync这类库默认用系统时间算锁剩余时间，但各机器时钟不同步会导致误判；得配 NTP 且容忍误差 ≤100ms - 除非你有跨机房部署、强一致要求、且已确认单实例方案扛不住，否则先用单实例 + 正确的 SET + Lua 删除
锁续期（renew）什么时候必须做
当业务执行时间不可控（比如要调外部 HTTP 接口、处理大文件、等用户回调），且超时时间没法预估时，才需要自动续期。
Go 里常见做法是启动一个后台 goroutine，在锁过期前 1/3 时间调用 GetExpiry 拿剩余 TTL，再用 Lua 脚本更新过期时间。但注意：这个 Lua 脚本也得校验 value，否则又是误续别人锁。
- 续期不是“每秒刷一次”，而是按锁初始 TTL 动态算下次续期时间，避免高频打 Redis
- goroutine 必须绑定到锁生命周期：加锁成功后才启，释放锁或 context cancel 时 stop，否则 goroutine 泄漏
- 别依赖
PTTL命令：有些 Redis 代理（如 Twemproxy）不支持，得用GET+ 业务层记录时间戳的方式兜底
真正难的从来不是“怎么写锁”，而是“哪里该加锁、加多长、谁负责清理”。比如扣库存用 Redis 锁，但订单创建失败后，锁释放了库存却没回滚，这已经不是锁的问题了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
