加锁必须用 client.Set + NX + PX，不能用 SetNX；因网关层每秒可能扛数万请求，client.SetNX 是高危操作，它在 Redis 中不具备原子性且易导致锁失效。
加锁必须用 client.Set + NX + PX，不能用 SetNX
网关层每秒可能扛数万请求，用 client.SetNX 是高危操作。它在 Redis SETNX + EXPIRE 两步，中间若进程 panic、网络抖动或 OOM，key 就永久卡住——锁不释放，整个服务就挂死。
正确做法是显式调用 client.Set，并传入 redis.WithValue 和 redis.WithExpiration：
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
ok, err := rdb.Set(ctx, key, token, redis.WithValue(token), redis.WithExpiration(10*time.Second)).Result()
if err != nil || !ok {
return errors.New("acquire lock failed")
}-
token必须是每个请求独立生成的，比如uuid.NewString()，不能复用或写死 -
10*time.Second是建议值：取网关 P99 耗时 × 2（如鉴权+路由平均耗时 3s，则设 6s），上限别超 30s，避免主从延迟导致误释放 - 不要把
time.Second误乘成纳秒传给 EX ——10 * time.Second是 10 秒，10 * time.Second.Nanoseconds()是 10⁹ 秒
解锁必须走 Lua 脚本，禁止 GET+DEL 或 Del 单独调用
网关里常见错误是先 rdb.Get 判断 value，再 rdb.Del —— 这两步之间存在竞态窗口。A 拿到锁后处理慢，超时自动过期；B 抢到新锁；A 结束时仍执行 Del，直接删掉 B 的锁，后续请求全被放行，流量拦截彻底失效。
唯一安全方式是用固定 Lua 脚本原子校验并删除：
立即学习“go语言免费学习笔记（深入）”；
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
const unlockLua = `if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end`
unlockScript := redis.NewScript(unlockLua)
<p>res, err := unlockScript.Eval(ctx, rdb, []string{key}, token).Result()
if err != nil {
log.Warn("unlock eval failed", "err", err)
return
}
if res != int64(1) {
log.Warn("unlock failed: not owner", "key", key)
return // 不是持有者，立刻中止，不重试
}- 脚本必须用
embed.FS或const硬编码，不能拼接字符串，方便审计和灰度替换 - 调用时参数顺序不能错：
[]string{key}是 KEYS，token是 ARGV[1] - 返回值不是
int64(1)就代表失败，此时业务逻辑必须立即退出，而不是重试或忽略
网关场景下要不要续期？只在明确长耗时路径开
普通鉴权、路由匹配、Header 透传这类操作通常
- 启动独立 goroutine，在锁剩余时间约 1/3 时触发续期（例如 TTL=15s，则每 5s 检查一次）
- 续期也必须用 Lua 校验 ownership，不能无脑
PEXPIRE，否则可能出现“锁已转移你还续着”的脏状态 - 续期脚本和解锁脚本结构类似，只是把
del换成PEXPIRE，且需传新 TTL（毫秒） - 续期 goroutine 必须绑定
context.WithCancel，业务结束或锁释放时立即 stop，避免 goroutine 泄漏
多实例网关共享锁，别碰 Redlock
Redlock 在网关这种低延迟、高吞吐场景下是过度设计。它要求至少 3 个独立 Redis 实例、多数派投票、总耗时检查，引入额外网络往返和失败分支，反而拖慢拦截速度，还增加运维复杂度。
真实生产中，一个高可用 Redis 集群（含哨兵或 Redis Cluster）+ 正确的原子加锁/解锁方案，已足够覆盖 99.9% 的网关流量拦截需求。
- 确保 Redis 客户端连接池配置合理：
MaxIdle≥ 20，MaxActive≥ 100，避免连接争抢 - key 命名必须带业务前缀和维度标识，比如
"gw:rate:ip:192.168.1.100"或"gw:lock:api:/v1/order/create" - Redis 8.2.3 已修复 CVE-2025-62507，建议升级，避免 RCE 风险影响网关边界安全
最易被忽略的是：锁的 value 不唯一、解锁不校验、TTL 设得比业务实际耗时还短——这三件事任何一件出错，都会让流量拦截形同虚设。
