Kratos中Redis分布式锁防击穿仍超时失败，因未设过期时间或过期时间短于DB查询耗时导致锁提前释放；需用SET key value NX EX原子命令（如EX 10），并根据DB P99耗时上浮50%设值，禁用直接DEL，改用Lua脚本校验value后删除，且外层加指数退避应对网络抖动。
Kratos里用Redis分布式锁防击穿，为什么还会超时失败？
因为SETNX加锁后没设过期时间，或过期时间短于DB查询耗时，锁提前释放，导致多个请求同时回源。Kratos默认不封装锁续期逻辑，得自己补。
实操建议：
- 必须用
SET key value NX EX 10带EX参数，避免死锁；10秒是常见兜底值，但要根据实际DB查询P99耗时上浮50% - 不要在
try/finally里直接DEL，要用Lua脚本保证原子性：EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:sku_1001 abc123 - Kratos的
redis.Client不自动重试，网络抖动时SETNX返回nil，需在外层加简单指数退避
Kratos项目集成Singleflight，为什么只在单机生效？
Singleflight本质是进程内并发控制，Kratos默认用sync.Map + WaitGroup实现，天然不跨Pod。你看到“防击穿效果变弱”，大概率是流量被K8s Service轮询打到多个实例，每个实例各自维护一套callMap。
实操建议：
- 确认是否真需要分布式Singleflight：如果缓存本身是共享Redis，且DB查询耗时
- 若必须跨节点折叠，别自己造轮子——改用
groupcache/singleflight的FlightPool配合Redis Pub/Sub做轻量协调，但要注意消息延迟会增加首请求等待时间 - 更务实的做法：把Singleflight和逻辑过期组合用，在
Get方法里先查Redis，命中则直接返回；未命中且expire_at已过，才触发Singleflight去重建
Kratos中Singleflight的panic常发生在哪几个地方？
最典型的是Do回调里抛出未捕获异常，导致call.err为nil但call.val也为空，后续result.(T)类型断言失败panic。Kratos的transport/http中间件不会自动recover这类错误。
实操建议：
- 所有传给
singleflight.Group.Do的函数，必须用defer func(){ if r := recover(); r != nil { log.Error(r) } }()兜底 - 不要在
Do回调里直接操作Kratos的ctx，比如调用tracing.Inject——Do可能在goroutine里执行，原ctx已cancel - 检查
Do返回的err：如果是singleflight.ErrCanceled，说明该请求被取消，不应继续处理结果
为什么开了Singleflight，监控里DB QPS还是没降下来？
因为Singleflight只折叠“完全相同key”的请求，而业务代码里key拼接方式不一致：比如"user:" + id和"user:" + strconv.Itoa(id)在Go里生成不同字符串；或HTTP参数顺序不同导致query部分hash不一致。
实操建议：
- 统一用
fmt.Sprintf("user:%d", id)而非字符串拼接，避免空格/类型隐式转换差异 - 对HTTP请求，用
url.Values.Encode()标准化query参数，而不是直接取r.URL.RawQuery - 在
Do前加日志打印key，抽样对比10个并发请求的key是否真一致——这是90%线上问题的根因
Kratos里缓存击穿防护的关键不在选哪个方案，而在让Singleflight的key真正“可折叠”、让分布式锁的生命周期真正“可覆盖DB耗时”。这两点漏掉任何一个，再漂亮的架构设计都会在凌晨两点的告警电话里失效。
