缓存穿透防护必须严格串联布隆过滤器、空值缓存和singleflight三者：bloom.Test()须前置且key与DB完全一致；空值缓存需用显式Null类型并设短TTL；singleflight的key须分离且非法输入须提前拦截。
缓存穿透防护不是“选一个方案就行”，而是必须把 bloom.Test()、空值缓存、singleflight.Do 三者串成一条不可跳过的链——漏掉任一环，攻击流量就能绕过拦截直打数据库。
布隆过滤器必须放在最前面，且 key 格式要和 DB 写入完全一致
很多人把 bloom.Test() 放在 cache.Get() 后面，结果过滤器成了“补刀工具”：缓存没命中才去测，等于已经放行了一次无效请求。真正有效的顺序是：收到请求 → 立即用 bloom.Test([]byte("user:" + id)) 判断 → 返回 false 就直接 return nil, errors.New("not found")，不查缓存、不查 DB、不进 singleflight。
- key 必须和 DB 主键/索引字段严格对齐：DB 存的是
"user:123"，布隆里加和测的都得是这个字符串，不能是"123"或"USER:123" - 若 id 来自 HTTP 查询参数且含结构（如 JSON 字符串），先哈希再测：
sha256.Sum256([]byte(rawKey)).Sum(nil)，避免格式差异导致误判 - 布隆过滤器变量必须是包级全局单例，不能在闭包里每次
new；预热必须在启动时全量加载，后续 DB 新增数据必须同步调用filter.Add()
空值缓存不能存 nil，得用显式占位类型
写 cache.Set(key, nil, ttl) 是危险操作：不同缓存库序列化行为不一致，有的存成字符串 "<nil>"</nil>，有的存成 NULL，读出来后 val == nil 永远为 false，空值缓存就失效了。
- 定义统一空值类型：
type Null struct{} - 写缓存：
cache.Set(key, Null{}, 2*time.Second) - 读缓存后判断：
if _, ok := val.(Null); ok { return nil, errors.New("not found") } - TTL 要短（建议 1–5 秒），避免合法数据上线后被长期锁死
singleflight.Do 的 key 必须和缓存 key 分离，且非法输入要提前拦截
直接传缓存 key 给 g.Do(cacheKey, ...) 是高危操作：恶意 key（如 "user:-1"）也会触发 goroutine 合并等待，CPU 和协程全耗在无意义阻塞上。
立即学习“go语言免费学习笔记（深入）”；
-
Do的 key 应标识“实际操作”，例如"db:get_user_by_id:" + id或"rpc:fetch_profile:" + id - 非法 id（含字母、超长、负数）必须在进
Do前就return，不参与合并 -
Do回调里必须包含完整副作用：查 DB → 判空 → 写空值缓存 → 返回结果；缺一不可 - 写空值缓存必须检查
err：if err := cache.Set(key, Null{}, ttl); err != nil { /* 记录日志，但不 panic */ }
最易被忽略的一点：布隆过滤器本身不防穿透，它只是个概率型存在判断；真正兜底的是「空值缓存 + singleflight」组合。但如果 key 格式不一致、预热没做、Test() 位置错了，那整个防护链从第一环就断了——后面再严谨也没用。
