不能直接用gorm钩子自动删redis缓存，因为钩子仅对单次save/delete生效，无法覆盖原生sql、批量操作、事务嵌套或跨service调用；且无超时控制，redis失败会阻塞db事务。
为什么不能直接用 GORM 的钩子自动删 Redis 缓存
很多人一上来就想在 AfterUpdate 或 AfterDelete 钩子里调 rdb.Del，结果上线后发现缓存没删、删错 key、甚至删了不该删的。根本原因是：GORM 钩子只对单次 Save/Delete 生效，但业务层常走原生 SQL（比如批量更新）、事务嵌套、或跨 service 调用，钩子根本收不到通知。更麻烦的是，钩子执行时没有上下文超时控制，Redis 连接失败会卡住整个 DB 事务。
实操建议：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 禁用所有 GORM 钩子做缓存清理，统一收口到业务方法里
- 每个写操作（如
UpdateShop）必须显式调用delShopCache(id)，且该函数内部用带超时的context.WithTimeout - 如果用了
gorm.Session(&gorm.Session{NewDB: true})创建新 DB 实例，钩子默认不继承——这点极易被忽略
Del 操作失败时怎么兜底
线上最常见现象是：数据库更新成功了，rdb.Del(ctx, "shop:123") 却因网络抖动返回 redis: connection pool timeout，导致缓存一直脏着。这时候不能重试（可能放大雪崩），也不能静默吞错（一致性彻底崩）。
实操建议：
- 对关键写操作（如店铺核心字段更新），
Del失败时记录告警日志并触发异步补偿任务（例如发消息到 Kafka，由独立消费者重试最多 3 次） - 非关键字段（如店铺 banner 图 URL）可降级为“延迟双删”：先删一次，
time.AfterFunc(500*time.Millisecond, func(){ rdb.Del(...) }) - 所有
Del必须设超时，例如ctx, _ := context.WithTimeout(r.Context(), 200*time.Millisecond)，避免阻塞主流程
行级缓存 key 设计要防冲突和穿透
直接拼 "shop:" + strconv.Itoa(id) 看似简单，但实际会踩两个坑：一是用户传恶意字符串（如 id=123:abc）导致 key 冲突；二是空查时没写空值，引发缓存穿透。
实操建议：
- key 前缀强制加业务域，如
"shop:detail:" + strconv.Itoa(id)，禁止裸用数字 ID - ID 必须校验为正整数，否则直接返回错误，不进缓存/DB 流程
- DB 查询返回
gorm.ErrRecordNotFound时，必须写空值：rdb.Set(ctx, key, "null", 60*time.Second) - 读取缓存后，先判断
val == "null"再决定是否查 DB，避免反复穿透
并发更新下怎么避免脏数据覆盖
典型场景：A 请求刚删完缓存，B 请求查 DB 拿到旧数据并回填缓存，A 才完成 DB 更新——最终缓存里是旧值。这不是概率问题，QPS > 50 就大概率复现。
实操建议：
- 对高敏感字段（如库存、价格），写操作加分布式锁：
lockKey := "lock:shop:update:" + strconv.Itoa(id)，用SET lockKey 1 NX EX 10实现 - 锁必须带随机 value（防误删），释放前用 Lua 脚本比对再删
- 读操作不加锁，但用
singleflight.Group包住 DB 查询，避免多个请求同时回源 - 不要依赖“先删缓存再更新 DB”的顺序来保一致——它在并发下天然不可靠，得靠锁或版本号
rdb.Del，而是让所有写入口都经过同一套超时、重试、空值、锁的约束。
