缓存穿透的本质是大量请求携带根本不存在的key导致缓存未命中而直接压垮数据库，防护需结合布隆过滤器预检、带类型与TTL的空值缓存及singleflight请求合并三者协同。
缓存穿透的本质是查了不该查的 key
缓存穿透不是并发高导致的，而是大量请求携带**根本不存在的 key**（比如恶意构造的 user_id=9999999999），缓存没命中，直接打到数据库，把 DB 打挂。核心判断标准就一条：缓存里没有，DB 里也确定没有——但请求还一个劲儿来。
所以防护的关键不是“挡并发”，而是“提前确认这个 key 绝对不存在”。常见错误是只加空值缓存（set("user:9999999999", nil, 5 * time.Minute)），但没处理好空值的类型、序列化方式、以及过期时间策略，结果空值本身被缓存污染或误判。
用布隆过滤器预检非法 key（Go 实现要点）
布隆过滤器（Bloom Filter）是解决“key 是否可能存在于集合中”的概率型数据结构，适合做前置轻量级拦截。Go 生态里推荐用 github.com/yourbasic/bloom 或 golang.org/x/exp/bloom（后者需 Go 1.21+）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 初始化时加载所有「合法存在」的 key 前缀或 ID 范围（比如已注册用户 ID 全集），而不是运行时动态写入——布隆过滤器不支持删除，写错就废了
- 过滤器大小要按预期总量预估：
filter := bloom.New(uint(10_000_000), 0.01)表示支撑一千万个 key、误判率约 1% - 每次查询前先
filter.Test([]byte("user:" + id))，返回false就直接拒绝，不走缓存和 DB - 注意：布隆过滤器只能防“不存在”，不能替代缓存；它不保证 100% 准确，但能拦下 99% 的穿透流量
空值缓存必须带明确类型与 TTL，且避免 JSON null 陷阱
当布隆过滤器放行后，仍可能遇到真实但暂时不存在的 key（比如刚注册还没写缓存）。这时需要缓存空结果，但很多人踩坑在：redis.Set(ctx, key, nil, expire) 在 Go-Redis 中实际会存成字符串 "<nil>"</nil>，下次 Get 返回非空字符串，导致逻辑误判。
正确做法是显式序列化空状态：
- 统一用结构体表示结果，比如
type UserResp struct { Data *User `json:"data"` NotFound bool `json:"not_found"` } - 查不到时缓存
json.Marshal(UserResp{NotFound: true})，而不是nil - TTL 要明显短于正常缓存（比如 2 分钟），防止合法数据上线后长期被空值锁死
- 别用
redis.String()直接解包，要用redis.Get(ctx, key).Result()拿原始字节再json.Unmarshal
布隆过滤器 + 空值缓存 + 请求合并，三者缺一不可
单靠一种手段都会漏：布隆有误判率，空值缓存会被击穿（比如缓存过期瞬间多个请求同时抵达），而高并发下重复查同一个不存在 key 仍可能压垮 DB。
必须补上第三层：请求合并（singleflight）。用 golang.org/x/sync/singleflight 包，在 key 未命中缓存时，让同一批并发请求共用一次 DB 查询。
- 代码模式是：
v, err, _ := sg.Do(key, func() (interface{}, error) { return db.Query(...), nil }) - 即使空值也要走
sg.Do，否则布隆放过、空缓存未建、多个请求同时打 DB - 注意：singleflight 不解决“恶意 key”问题，它只减少重复查询，必须和前两层配合
真正容易被忽略的是布隆过滤器的更新机制——线上 ID 集合变化时，你没法热更新 filter，只能全量重建并切流。这意味着防护体系里必须留出降级路径：比如布隆服务不可用时，自动 fallback 到更短 TTL 的空值缓存 + 更激进的限流。
