Beego 本身不提供分布式锁，需集成 Redis 并封装原子加锁（SET key value NX PX）与 Lua 校验解锁逻辑；sync.Mutex 和 synchronized 不适用于多实例场景，因前者仅限单进程、后者在 Go 中不存在，跨机器互斥必须依赖 Redis 等共享存储。
Beego 本身不提供分布式锁，你得自己集成 Redis 并封装安全的加解锁逻辑；直接在 Controller 里裸调 redis.Conn.Do("SET", ...) 极易因返回值误判、超时未设、value 不唯一导致锁失效或误删。
为什么不能用 sync.Mutex 或 Java 风格的 synchronized
Beego 多实例部署时，sync.Mutex 只作用于单进程内存，不同 Pod 或 Docker 容器之间完全隔离；Go 语言压根没有 synchronized 关键字。跨机器互斥必须依赖外部共享存储，Redis 是最轻量且适合 Beego 场景的选择。
SET key value NX PX 是加锁的唯一安全起点
必须用原子命令一次性完成“不存在才设 + 设置过期”，不能拆成 SETNX + EXPIRE（存在竞态窗口）。关键参数含义：
-
NX：保证互斥，key 已存在时整个命令返回nil -
PX 30000：毫秒级过期，防客户端崩溃导致死锁 -
value必须是全局唯一标识，如hostname+pid或 UUID，不能写死为"1"或"lock" - Go 客户端（如
go-redis）调用后需显式判断返回是否为"OK"，nil表示失败但常被忽略
解锁必须用 Lua 脚本校验 value 再删
直接 DEL lock:key 会误删别人持有的锁——比如 A 加锁后卡住超时释放，B 成功加锁，A 这时才执行 DEL，就把 B 的锁干掉了。正确做法是：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end这个脚本必须通过 Eval 执行，且传入的 ARGV[1] 必须和加锁时的 value 完全一致。Beego 中不要把锁逻辑写在 Controller 方法里，应封装为独立结构体（如 RedisLock），并通过依赖注入或全局单例管理 Redis 客户端连接池。
Beego 启动阶段最容易被忽略的三个坑
锁失效往往不是逻辑错，而是和 Beego 生命周期/配置耦合出问题：
-
redis.Conn连接池未预热，高并发下大量DialTimeout（如设成100 * time.Millisecond）导致加锁返回nil却没报错 -
Controller是短生命周期对象，若把*RedisLock实例存为字段，每次请求都新建，无法复用连接池 - 没加日志或监控，加锁失败时静默跳过，业务看似正常实则已退化为无锁状态
真正难的不是写对那几行 Redis 命令，而是让锁在 Beego 的启动流程、错误处理、连接池配置、日志埋点中稳定存活 —— 这些地方一漏，线上就容易出现“锁形同虚设”的隐性故障。
