sync.Mutex不能用于Beego中间件分布式锁，因其仅限单进程有效；多实例部署时锁互不可见，易致超卖；必须使用Redis等外部协调服务，配合带TTL和Lua校验的原子操作实现。
Beego中间件里不能直接用sync.Mutex做分布式锁
sync.Mutex只在单进程内有效，Beego部署多实例时，A实例加的锁对B实例完全无效。常见错误是：在Prepare()里写mu.Lock()保护库存检查，结果8万并发下5个实例同时读到stock=1，全部扣减——超卖就从这儿开始。
真正要防的是跨进程竞争，必须用外部协调服务。ZooKeeper、Redis或Etcd才具备分布式锁能力，其中Redis+SETNX+Lua最轻量、落地最快。
- 别把
redis.SetNX()当锁用：没过期时间，进程崩溃后锁永远不释放 - 必须带
EX参数设置TTL，推荐2~5秒（比业务逻辑长但远小于用户等待阈值） - 解锁不能简单DEL：得用Lua脚本先校验key值再删，防止A删了B的锁
- Beego中间件中调用锁操作前，务必用
ctx.Input.IP()或c.Ctx.Input.Param(":id")提取业务粒度（如商品ID），锁名得是"lock:sku:1001"这种，不能全局一把锁
用Redis Lua脚本实现可重入、带自动续期的分布式锁
Beego Controller生命周期短，但秒杀下单流程可能涉及多次DB查、MQ发、回调验，锁持有时间不可控。硬设5秒TTL容易被中断导致误释放，所以得靠Lua脚本原子判断+续期。
示例锁脚本（存为lockScript）：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("PEXPIRE", KEYS[1], ARGV[2])
else
return redis.call("SET", KEYS[1], ARGV[1], "NX", "PX", ARGV[2])
end
调用时传入KEYS = {"lock:sku:1001"}、ARGV = {random_token, "3000"}（毫秒）。token保证只有加锁者能续期，避免误删。
- Beego中间件里不要自己生成token——用
uuid.NewString()，别用时间戳或PID，易碰撞 - 每次续期前检查剩余TTL，低于1秒就放弃续期，转为失败处理
- 锁获取失败时，
c.Abort("429")比c.Data["json"] = ...更合适，避免下游解析空JSON
Beego Filter中间件注册锁逻辑的正确姿势
很多人在beego.InsertFilter()里直接写锁逻辑，结果发现Prepare()还没执行锁就释放了——因为Filter链执行完才进Controller方法。锁必须包在Filter闭包里，并手动控制生命周期。
正确写法：
beego.InsertFilter("/seckill/*", beego.BeeApp.Handlers, func(ctx *context.Context) {
key := "lock:sku:" + ctx.Input.Param(":id")
token := uuid.NewString()
// 执行lockScript，成功则存token到ctx.Input.Data
if ok, _ := lockScript.Run(ctx.Input.Ctx, rdb, []string{key}, token, "3000").Result(); ok == int64(1) {
ctx.Input.Data["lock_token"] = token
ctx.Input.Data["lock_key"] = key
return
}
ctx.Abort("429")
}, false)
- 别在Filter里defer unlock：ctx生命周期结束时Filter已退出，defer不会触发
- 解锁必须放在Post()末尾或defer里，且要检查
ctx.Input.Data["lock_token"] != nil - 如果Controller里发生panic，需在recover后主动调用解锁脚本，否则锁残留
为什么ZooKeeper锁在Beego里反而难落地
ZooKeeper的CreateSequential锁语义强，但Beego默认不内置zk客户端，引入github.com/samuel/go-zookeeper/zk后，连接管理、session超时重连、watch回调与HTTP请求生命周期对不齐——最容易出的问题是：zk session过期了，Beego还在用旧句柄调Exists()，返回zk.ErrNoNode却被当成业务错误吞掉。
相比之下，Redis连接池（github.com/redis/go-redis/v9）和Beego天然适配：
-
rdb := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379"})可全局复用，Beego启动时初始化一次就行 - Redis命令失败基本是网络或key问题，错误类型明确（
redis.Nil、redis.Timeout），好做降级 - ZooKeeper锁需要维护ephemeral node和watcher，而Beego每个请求都是无状态短连接，watch回调无法绑定到具体HTTP上下文
真要用ZooKeeper，得自己封装一个带context.CancelFunc感知的锁管理器，比写Redis Lua脚本成本高得多——除非你已经在用zk做服务发现，否则没必要为了锁再上一套zk。
