Kratos中RedissonClient注入失败致lock为nil，主因未封装为Provider并显式声明于wire.go；锁key须带业务分段（如activityID、productId、userID%segmentCount），tryLock的waitTime和leaseTime需按SLA与最大耗时合理配置，并解锁前校验IsHeldByCurrentThread()。
RedissonClient 注入失败导致 lock 为 nil
这是最常踩的坑：在 Kratos 中直接 redissonClient.GetLock(key) 调用，结果 panic 报 nil pointer dereference。根本原因不是锁逻辑写错了，而是 RedissonClient 根本没注入成功。
Wire 依赖注入不支持直接 new 出 RedissonClient 实例，它必须由 Config 构建，且生命周期需与 App 对齐。硬塞进 wire.go 里会失效。
- 必须封装为 Provider 函数，例如
NewRedissonClient(*redis.Options) *redisson.Client - 在
wire.go的ProviderSet中显式声明：wire.NewSet(NewRedissonClient) - 该 Provider 必须放在
data/redis/下，并由data.NewData()统一初始化，确保早于 service 层构建
漏掉任一环节，redissonClient 就是 nil，后续所有 tryLock 都会 panic。
锁 key 设计不合理引发串行瓶颈
写成 "lock:product:" + productId 看似简单，实则把整个秒杀流量压到一把锁上——所有用户抢同一商品都得排队，吞吐量归零，这不是防超卖，是制造单点。
多实例部署下，分布式锁确实能保原子性，但 key 必须带分段维度，否则并发能力完全丢失。
- 推荐组合 key：
fmt.Sprintf("seckill:%s:prod:%d:seg:%d", activityID, productId, userID%segmentCount) -
segmentCount不能拍脑袋定，要按预估峰值 QPS 和单段平均处理耗时反推（例如单段极限 200 QPS，峰值 1000 QPS → 至少 5 段） - key 中必须含
activityID或时间戳，避免不同批次活动复用旧锁，导致误删或冲突
tryLock 参数配错导致锁失效或饥饿
Kratos service 调用 redissonClient.GetLock(key).TryLock(waitTime, leaseTime, timeUnit) 时，两个时间参数极易设错：
-
waitTime（最大等待时间）设太小（如100ms），高并发下大量请求直接返回失败，用户看到“稍后再试”，体验断层 -
leaseTime（锁持有时间）设太短（如3s），而实际业务逻辑耗时超过该值，锁自动释放，其他协程趁虚而入，导致超卖 - 建议：leaseTime ≥ 业务最大可能耗时 × 1.5；waitTime 根据接口 SLA 定（如 99% 请求应在 800ms 内完成，则设为
800）
另外，解锁前必须校验 lock.IsHeldByCurrentThread()，否则可能误删别人持有的锁。
分段锁空段未主动 fallback
按 userID % segmentCount 分段后，若某段库存已空，当前请求不能卡在 tryLock 上死等——它应该主动释放锁、尝试下一组 key，否则线程阻塞，QPS 断崖下跌。
典型错误是只做一次 tryLock，成功才继续；正确做法是循环尝试多个分段，直到成功或全部失败：
- 生成一组候选 key（如 seg0 ~ seg4）
- 对每个 key 调用
tryLock，成功则立即执行扣减逻辑并 break - 失败则调用
lock.unlock()（仅当IsHeldByCurrentThread()为 true 时） - 全部尝试失败后，统一返回库存不足
这个 fallback 逻辑容易被忽略，但它决定了分段锁是否真能提升并发，还是只是换了个方式卡死。
