Redis的SETNX命令只接受key和value两个参数若用Do方法多传参数如EX会导致协议解析失败而返回nil应改用SET命令的NXEX选项或go-redis/v9的SetNX方法。redis.Client.Do 调用 SETNX 为什么总是返回 nilGo 用 redis.Client.Do 直接发 SETNX 命令结果拿到 nil不是 1 或 0 —— 这大概率是命令参数传错了。Redis 的 SETNX 只接受两个参数key 和 value但 Go 的 Do 方法会把每个参数单独序列化如果你写了 c.Do(SETNX, mylock, abc, EX, 10)Redis 实际收到的是 5 个参数它不认识 EX直接忽略后续只执行 SETNX mylock abc然后返回 1 或 0但如果你多传了比如误加了 nil 或空字符串底层协议解析失败就可能返回 nil。更稳妥的做法是改用 SETEX 或推荐SET 命令的原子选项c.Do(SET, mylock, abc, NX, EX, 10) —— 注意顺序NX 和 EX 是 flag不是值必须紧挨在 value 后面用官方 github.com/go-redis/redis/v9 的 SetNX 方法自动处理类型和错误返回 bool, error别自己拼 Do除非你明确需要绕过 client 封装做特殊协议操作用 redigo 还是 go-redis/v9锁超时后自动续期怎么做选 go-redis/v9。redigo 是低层封装所有命令都要自己处理连接、重试、类型转换而分布式锁的核心难点不在“设个 key”而在“持有期间续期”和“释放时校验所有权”。v9 提供 Lock / Unlock 接口背后用 Lua 脚本保证删除操作的原子性只删自己设的 valueredigo 没这层能力得自己写脚本、自己 EVAL、自己比对 value极易出错。自动续期renew不是开个 goroutine 定时 EXPIRE —— 那不原子且无法判断锁是否已被别人抢走。正确做法是立即学习“go语言免费学习笔记深入”初始化锁时传入 WithContext WithExpiration并启用 WithAutoRefresh锁对象内部起一个 ticker在剩余 TTL 的 1/3 时间点尝试刷新需服务端支持v9 默认开启刷新失败比如锁已丢失会触发回调你可以选择 panic 或降级逻辑注意auto-refresh 不是无限续它只在锁仍被当前客户端持有时才生效解锁时报 “ERR no such key” 或 “attempt to unlock unlocked mutex”这不是 Redis 报错是客户端库如 go-redis/v9 的 mutex 包抛的 panic。根本原因是你调用了 Unlock但此时 key 已过期、被别的客户端覆盖、或压根没成功加锁比如 SetNX 返回 false 却没检查。 AI智研社 AI智研社是一个专注于人工智能领域的综合性平台