Redis不内置Bloom Filter，需借助Redisson等第三方实现；EXISTS和空值缓存无法有效防穿透，因前者不拦截非法ID、后者易致缓存污染；布隆过滤器以极小空间开销提供高效存在性否定判断。
Redis 本身不内置 Bloom Filter，必须借助第三方实现（如 Redisson、Redission、或服务端自己维护 bitmap）才能用它防缓存穿透；直接在 redis-cli 里执行 BLOOM 命令会报错 —— 那是 Redis 7.0+ 的 BF.* 模块命令，需显式加载模块且不是所有部署都默认启用。
为什么不能只靠 EXISTS 或空值缓存来防穿透
因为 EXISTS key 只能查 Redis 里有没有这个 key，对「数据库根本不存在的非法 ID」毫无拦截能力；而空值缓存（比如 SET user:999999 "" EX 60）虽然能挡一次，但面对海量恶意构造的 key（如 user:1234567890、user:abc），会导致缓存被污染、内存暴涨，甚至触发淘汰策略误删有效数据。布隆过滤器的位图结构天然适合做「存在性快速否定」——它不存原始数据，只存哈希指纹，空间开销极小，且查询是 O(k) 时间（k 是哈希函数个数）。
Redisson 的 RBloomFilter 怎么初始化才不踩坑
常见错误是没设好预期插入量 expectedInsertions 和误差率 errorRate，导致后期 false positive（误判存在）飙升或位图撑爆内存。实际初始化时注意：
-
expectedInsertions要按「业务全量合法 key 的上限」预估，比如用户表最多 5000 万用户，就填50_000_000，不能填日活或月活 -
errorRate别盲目设 0.01（1%），生产环境建议 0.03～0.05；低于 0.01 会使位图体积翻倍，但 false positive 下降并不线性 - 务必在应用启动时一次性
RBloomFilter.tryInit()，否则首次add()会触发自动扩容，可能因并发写入导致结构不一致 - 不要把布隆过滤器当数据库用 —— 它不支持
delete，也不保证 100% 准确；mightContain(key)返回false才能确定 key 绝对不存在，返回true仍需查缓存/DB
请求链路中布隆过滤器该插在哪儿
位置错了等于白加。典型错误是把它放在缓存之后（先查 Redis，没命中再过布隆），这完全失去意义。正确顺序必须是：
请求 → RBloomFilter.mightContain("user:12345") → 若返回 false，直接返回 404 或空响应；若返回 true，再查 Redis 缓存 → 缓存 miss 再查 DB → DB 查不到则不写回布隆（避免把非法 key 也“记住”）→ DB 查到则 add 到布隆（仅对确认合法的 key）
关键点：布隆只负责「守大门」，不是「查户口」；所有写入布隆的操作，必须来自 DB 确认存在的数据源，不能由用户输入直接触发 add。
真正难的是冷启动 —— 新系统上线时布隆过滤器为空，所有请求都会被放行，这时候得配合空值缓存兜底，或者用离线脚本把历史合法 key 预热进去。另外，布隆过滤器无法应对 key 规则变化（比如从 user:id 改成 u:id），这种时候旧布隆就失效了，得滚动重建，而不是简单清空重来。
