go-zero的redislock必须显式调用setexpire()设置过期时间，否则默认无过期导致永生锁；加锁与解锁均通过lua脚本原子执行，确保value匹配才释放，防止误删他人锁。
Go-Zero 的 RedisLock 怎么用才安全？
直接调用 Acquire() 而不设过期时间，等于把锁变成“永生锁”——一旦客户端崩溃或网络中断，锁永远不释放。Go-Zero 的 RedisLock 默认不设 seconds，必须显式调用 SetExpire()。
常见错误是：先 NewRedisLock(store, "key")，然后直接 Acquire()，结果锁没过期时间，Redis 中 key 永久存在。
-
SetExpire(5)表示 5 秒后自动过期，建议值 ≤ 业务最长执行时间 × 1.5（留出网络与 GC 波动余量） - 不要依赖
Release()主动释放来兜底——它可能因 panic、context cancel 或网络失败而跳过 - 若业务逻辑可能超时，需配合
AcquireCtx(ctx)+context.WithTimeout()控制获取锁的等待上限
为什么 Unlock 必须用 Lua 脚本？
直接用 DEL 删除 key 是危险操作。比如 A 获取了锁，但执行慢；B 等待超时后也拿到了锁（因为 A 的锁已过期）；此时 A 执行完调 Del("key")，实际删的是 B 的锁——造成并发冲突。
Go-Zero 的 ReleaseCtx() 内部执行的是 Lua 脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
这个脚本保证：只有值匹配当前 client 的 id（即初始化时生成的唯一字符串），才能删 key。否则返回 0，不误删。
- 你的 lock 实例必须保持存活到
Release调用完成——id是实例内字段，不能跨 goroutine 复用 lock 对象 - 如果用了
defer lock.Release()，要确认 defer 所在函数的生命周期覆盖完整业务逻辑，否则可能提前释放
redsync 和 Go-Zero 的锁，选哪个？
Go-Zero 的 RedisLock 是单节点、单 key、带可重入支持的轻量实现；redsync 是基于 Redlock 算法的多节点仲裁锁，目标是容错主从切换或单点故障。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
多数业务根本不需要 Redlock——它增加延迟、复杂度和运维成本，且 Redis 官方已弱化推荐（见 Redis 文档 2023 年后更新）。除非你满足以下全部条件：
- 部署了 ≥3 个物理隔离的 Redis 节点（非哨兵/集群模式下的分片）
- 业务对“绝对不允许多个节点同时持锁”有金融级要求（如支付扣款）
- 能接受加锁耗时翻 3 倍、失败率上升（网络抖动导致少数节点不可达）
否则，用 Go-Zero 自带的 RedisLock 更稳。它的 Lua 加锁脚本已包含可重入逻辑（检查 value 是否匹配），比手写 SETNX + EXPIRE 组合更可靠。
自动续期（看门狗）为什么没出现在 Go-Zero 官方实现里？
Go-Zero 的 redislock.go 当前版本（v1.6.x）**不提供自动续期**。它假设业务能在 SetExpire() 设置的时间内完成，超时即放弃或重试。
需要续期的场景（如长事务、流式处理、外部 API 调用不确定耗时），必须自行实现：
- 启动 goroutine，在锁剩余 TTL 的 1/3 时间点调用 Lua 续期脚本（类似你知识库中
keepAlive()的逻辑） - 续期脚本必须再次比对
value，防止续了别人的锁 - 注意 context 取消传播：续期 goroutine 应监听业务 ctx，而非 lock 自身的 long-lived ctx
真正容易被忽略的是：续期不是“延长 TTL”，而是“重置 TTL”。Redis 的 EXPIRE 对已存在的 key 有效，但如果你用 SET key val PX ms 覆盖，会丢失原 value，导致后续 Unlock 失效——必须用 GET + 判断 + EXPIRE 或原子 Lua。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
