防穿透需请求拦截、缓存预热、空值兜底三者协同，缺一不可；gin-vue-admin中仅靠redis.Get查缓存会因并发miss导致DB击穿，须用SetNX加锁+轮询+降级机制实现防穿透。
直接说结论：防穿透不是加一层缓存就能解决的，核心在于“请求拦截 + 缓存预热 + 空值/错误兜底”三者必须协同，缺一不可；否则缓存击穿照样发生，尤其在 gin-vue-admin 这类权限+字典高频读场景下。
为什么 redis.Get 直接查缓存会穿透？
常见错误是把缓存逻辑写成“先查 Redis，没命中就查 DB，再回填缓存”——这在并发请求打到同一 key 时，多个 goroutine 都会同时发现缓存 miss，然后全部涌向数据库。
典型现象：GET /api/v1/user/123 在秒级内被 200 个请求打中，Redis 中该 key 刚过期，结果 200 个 goroutine 全部执行 db.Query，DB CPU 瞬间拉满。
- 根本原因：缓存失效窗口 + 高并发请求 + 无同步控制 = 穿透风暴
- gin 本身不提供分布式锁原语，
redis.Get是纯读操作，不带原子性保障 - gin-vue-admin 的
system.LoadAll()只做启动预热，不解决运行时热点失效问题
用 redis.SetNX + time.AfterFunc 实现轻量防穿透
不需要引入额外组件（如 redlock），用 Redis 原生命令即可。关键不是“只让一个请求查 DB”，而是“让第一个 miss 的请求负责重建，其余等待结果”。
示例逻辑（放在 handler 或 service 层）：
// key := "user:123"
val, err := redisClient.Get(ctx, key).Result()
if err == redis.Nil {
// 尝试抢锁
ok, _ := redisClient.SetNX(ctx, key+":lock", "1", 3*time.Second).Result()
if ok {
// 抢到锁：查 DB → 写缓存 → 删除锁
data := queryFromDB(id)
redisClient.Set(ctx, key, data, 10*time.Minute)
redisClient.Del(ctx, key+":lock")
c.JSON(200, data)
} else {
// 没抢到锁：短暂轮询等待，避免长阻塞
for i := 0; i < 5; i++ {
time.Sleep(20 * time.Millisecond)
if val, _ := redisClient.Get(ctx, key).Result(); val != "" {
c.JSON(200, val)
return
}
}
// 超时降级：返回空或默认值，不抛错
c.JSON(200, defaultUser)
}
return
} else if err != nil {
c.JSON(500, gin.H{"error": "cache error"})
return
}
c.JSON(200, val)
-
SetNX是原子操作，天然防竞态；3 秒锁过期是为防 goroutine panic 导致锁残留 - 轮询用
time.Sleep而非time.Tick，避免 goroutine 泄漏 - 降级必须存在，否则等待锁失败后直接报错，等于把压力转给客户端重试
gin-vue-admin 里怎么改字典/权限缓存防穿透？
它的 sys_dictionary.go 和 sys_user.go 当前是“查不到就加载并 Set”，但没加锁——这就是穿透温床。
修改点集中在两个位置：
-
server/service/system/sys_dictionary.go的GetDictionary方法：把redis.Get+db.Find块包进上述SetNX流程 -
server/service/system/sys_user.go的UserAuthorityDefaultRouter调用链中，对authority_id对应菜单数据的加载，同样套防穿透逻辑 - 注意：本地缓存（
sync.Map）不能替代 Redis 锁，多实例部署下本地缓存无效
别忘了更新 server/global/global.go 里的全局 RedisClient 实例，确保它支持 SetNX 和 pipeline。
为什么不用布隆过滤器？
在 gin-vue-admin 这类业务中，90% 热点 key 是已知的（如固定字典 code、管理员 user_id），布隆过滤器反而增加误判和维护成本。
真正需要布隆过滤器的场景是：未知 key 的海量请求（如短链跳转），且能接受少量误判。而权限/字典数据有明确 ID 范围，预热 + 防穿透更稳。
容易被忽略的是：缓存 key 的命名一致性。比如字典数据用了 dict:status，但查询时拼成 dict_status，防穿透逻辑就完全失效——这种低级错误在线上日志里常表现为“大量 redis.Nil 但 DB 查询日志为空”。
