go网关用分布式锁防重复绑定uuid，本质是防并发写同一资源，必须用业务键（如user_id:device_id）加锁而非裸uuid；需token+lua原子释放、合理设超时，并叠加db唯一索引等最终一致性校验。
直接说结论：Go网关用分布式锁防重复绑定 UUID，本质是「防并发写同一资源」，不是单纯校验 UUID 是否存在；必须配合唯一业务键（如 user_id:device_id）加锁，不能对裸 UUID 加锁，否则锁粒度错、性能崩、还可能漏防。
为什么不能直接对 UUID 加锁
UUID 本身是全局唯一标识，但“重复绑定”问题的根源不是 UUID 冲突，而是多个请求并发试图把同一个设备（或用户+设备组合）绑定到不同账户。如果只用 uuid 作为锁 key：
- 所有请求都抢同一把锁（因为 UUID 相同），吞吐归零，网关变单点
- 实际要保护的是「某用户绑定某设备」这个动作，锁 key 应该是业务语义键，比如
"bind:u123:d456" - 攻击者若批量生成新 UUID，还能绕过锁——锁没拦住真正要防的冲突场景
TryLock 必须带 token 和 Lua 原子释放
用 Redis 实现时，SETNX 只能保证获取锁原子，但释放锁必须验证持有权，否则 A 拿到锁后超时，B 覆盖了 key，A 回来误删 B 的锁。正确姿势：
- 获取锁时生成随机
token（如uuid.NewString()），存入 value - 释放锁必须用 Lua 脚本：
EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end" 1 bind:u123:d456 abcdef... - 别用
Del直接删——这是最常踩的坑，90% 的线上锁失效都源于此
锁超时时间得比业务处理长，但不能太长
网关处理绑定逻辑通常很快（毫秒级），但下游服务可能延迟或重试。设锁过期时间要满足两个条件：
- 大于最大预期处理耗时（含网络抖动、下游超时重试），建议取
3–5 秒 - 小于业务允许的“最坏重试窗口”，比如前端最多重试 2 秒，那锁就不能设成 10 秒，否则第二次请求在第一次还没释放时就被拒，体验断层
- 绝对不要依赖 TTL 自动清理来兜底——Redis 故障重启后锁全丢，必须靠业务层二次校验（如 DB 唯一索引 or Redis
SETNX写绑定记录）
最终一致性校验不能省
分布式锁只能降低并发冲突概率，不能 100% 消除。真实生产环境必须叠加一层最终防护：
- 在数据库插入绑定记录时，强制加唯一索引，字段为
user_id + device_id - 或在 Redis 用
SETNX写一个业务态标记，key 是"bound:u123:d456"，value 是绑定时间戳，过期时间略长于锁（如 10 秒） - 如果锁内执行完发现 DB/Redis 写失败（唯一冲突），说明已有其他请求抢先完成，此时应返回「已绑定」而非报错
锁是减速带，唯一索引才是护栏。漏掉后者，高并发下一定出双绑。
