Beego中直接用redis.Client实现分布式锁易出错，因漏掉原子性（须用SET NX PX）、所有权校验（解锁需Lua脚本比对value）和续期控制（需绑定context的goroutine按TTL/3续期）。
Beego 中直接用 redis.Client 实现分布式锁为什么总出错
因为 Beego 本身不提供分布式锁封装，很多人直接在 controllers 或 models 里裸调 redis.Client.Set，结果漏掉三个关键点：原子性、所有权校验、续期控制。典型错误是写成 client.Set(ctx, "lock:key", "1", 30*time.Second) —— 没加 NX，别人能覆盖你的锁；或者解锁时直接 client.Del(ctx, "lock:key")，删掉了别人刚续上的锁。
- 加锁必须用
SET key value NX PX milliseconds，redis.Client的Set方法默认不带NX，得换用SetNX或手写Do("SET", key, value, "NX", "PX", ms) - 解锁必须走 Lua 脚本：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end，否则无法防止误删 - Beego 的 controller 生命周期短，业务还没跑完，controller 就返回了，续期 goroutine 容易被提前 GC 或没绑定 context 控制，变成“幽灵任务”
如何在 Beego 项目中安全启动续期 goroutine
不能在 func (c *OrderController) Post() 里直接 go renewLock(...)，那样续期逻辑和请求生命周期脱钩，panic、超时或连接中断后 goroutine 还在跑。必须把续期和请求的 context.Context 绑定。
- 从 Beego 的
c.Ctx.Request.Context()派生一个带 cancel 的子 context：ctx, cancel := context.WithCancel(c.Ctx.Request.Context()) - 启动续期 goroutine 前，用
defer cancel()确保 controller 返回时自动触发 cancel（注意：要放在 goroutine 启动之后，否则可能 cancel 太早） - 续期循环内部每次
time.Sleep前都检查ctx.Done()，遇到context.Canceled立即退出 - 续期间隔设为锁 TTL 的 1/3（比如 TTL=30s，sleep=10s），避免 Redis 压力过大，也留出网络抖动缓冲
Beego 集成 Redisson 的实际障碍
Redisson 是 Java 生态的，Go 项目没法直接用。有人想通过 HTTP bridge 或 gRPC 封装 Redisson 服务，但这样引入额外延迟和单点故障，在 Beego 这类轻量 Web 框架里得不偿失。真正可行的是用 Go 原生 Redis 客户端（如 github.com/go-redis/redis/v9）+ 自定义封装，而不是硬套 Redisson 模式。
-
redsync库虽支持 Redlock，但 Beego 项目通常只连单个 Redis，它带来的复杂度远大于收益 - 不要试图在 Beego 的
app.conf里配leaseTime=30然后幻想自动续期——Beego 没这个机制，续期逻辑必须自己写、自己控、自己测 - 如果真要用看门狗风格，建议封装一个
LockManager结构体，包含Acquire、Renew、Release三方法，并在Release内部做 token 校验 + Lua 删除
超时时间该设多少才不会引发秒杀超卖
不是拍脑袋写个 10 * time.Second 就行。电商秒杀场景下，库存扣减链路包括：查库存 → 扣减 → 写订单 → 发 MQ，P95 耗时可能达 800ms。设成 2 秒，GC 停顿或 Redis 网络抖动就容易触发锁过期；设成 30 秒，节点宕机后锁残留太久，整个商品池卡死。
- 先用 Beego 的
beego.BeeLogger记录每步耗时，统计真实 P95，再加 200~500ms 缓冲作为初始 TTL - 对长流程（如含外部 HTTP 调用），必须启用续期，且续期触发条件不能只依赖定时器——要结合业务进度，比如“扣减成功后才开始续期”，避免空跑
- 测试阶段务必模拟节点 kill -9，观察锁是否在 TTL 后自动释放，以及释放后是否被其他节点正确获取（用 Redis CLI 的
KEYS lock:*和TTL命令验证）
Beego 不是问题根源，但它的轻量设计意味着所有分布式锁细节都得你亲手抠——token 生成用 uuid.NewString()，不是 time.Now().Unix()；续期失败不能静默吞掉错误；controller 返回前必须确保 cancel() 已调用，否则 goroutine 泄漏会慢慢吃光 Redis 连接数。
