布隆过滤器必须前置强同步于缓存与数据库查询之前，全量预热合法key、格式严格对齐、参数按生命周期精准配置，Test为false时立即拦截，true时仍需二次查证。
Go 语言实现基于布隆过滤器的缓存穿透防御，核心不是“加个过滤器就完事”，而是让布隆过滤器真正扛起「第一道拒真」的责任——对确定不存在的 key，零延迟拦截，不走缓存、不查数据库。
布隆过滤器必须前置且强同步
它得在任何缓存 Get 或 DB 查询之前调用，且只对「合法存在」的 key 集合做初始化。不能靠运行时动态 Add，因为布隆过滤器不支持删除，写错或漏写就等于防线开洞。
- 初始化时从数据库或 Redis 全量加载所有有效 key（如用户 ID、商品 SKU），统一转为 []byte 后调用
filter.Add() - key 的格式必须和线上查询完全一致：大小写、前缀（如
"user:123"）、编码方式（UTF-8）、是否带 JSON 结构——哪怕多一个空格，Test()就会返回 false - 推荐使用 github.com/yourbasic/bloom，它自动对齐位数组、处理哈希一致性，避免手写导致的越界或误判翻倍
参数设置要贴合业务生命周期
n 和 p 不是拍脑袋填的数字，而是系统必须长期满足的硬约束：
-
n 是你整个服务生命周期内「最多插入多少唯一项」，比如用户表预计三年增长到 5000 万，则 n 至少设为
50_000_000；填小了，后期误判率会指数飙升 -
p 是可接受的误判率，常规防护选
0.01（1%）足够，已能拦截 99% 恶意 key；追求更严可设0.001，但内存几乎翻倍 - 示例：
bloom.New(10_000_000, 0.01)适合千万级商品 ID 拦截；bloom.New(1000, 0.0001)适合设备白名单等小而精场景
并发安全与正确调用链不可跳步
多个 goroutine 并发 Add() 必须加锁，但 Test() 可无锁——因为底层是 []byte，单字节读天然原子。
立即学习“go语言免费学习笔记（深入）”；
- 用 sync.RWMutex 包一层：Add 用
Lock()，Test 用RUnlock()（只读不阻塞） - 调用顺序铁律：
if !filter.Test(key) { return nil, false }→ 然后才走cache.Get()→ 若未命中，再考虑singleflight.Do()查 DB -
Test() == true只代表「可能存在」，绝不能直接返回成功；必须继续查 Redis 或 DB 做二次确认，否则就把误判当真相
别把布隆过滤器当黑盒，它需要主动运维
它没有自动扩容、无法删除、不感知数据变更，这些都得你兜底：
- 数据写入 DB 成功后，立刻同步
filter.Add([]byte(id))，确保读写强一致 - 预估总量快触顶时，提前分片（如按
id % 16分 16 个 filter）或定时重建全量过滤器 - 删数据时布隆里对应项无法清除，可接受短暂误判，靠空值缓存 TTL（如 5 分钟）+ 定期全量重建来收敛
- 过滤器建议常驻内存（全局变量），别存 Redis 或每次请求 new，否则序列化开销大、更新难、启动慢
