布隆过滤器需正确集成RedisBloom模块并预热，bfAdd与bfExists须严格配合业务流程，误判率和容量按实际key量计算，空值缓存兜底不可省略。
布隆过滤器不是“开了就防穿透”，在 C# 里用 Redis 做缓存穿透防护，关键得把 bfAdd、bfExists 和业务流程串对，否则要么漏判、要么误拦、要么拖慢请求。
RedisBloom 模块必须启用，别用纯内存实现
StackExchange.Redis 默认不支持布隆过滤器命令，直接调 bfExists 会报 ERR unknown command。你得确认 Redis 实例已加载 RedisBloom 模块（6.2+ 原生支持，但需显式加载）：
- 启动时加参数：
--loadmodule /path/to/redisbloom.so - 或运行命令：
MODULE LOAD /path/to/redisbloom.so - 验证是否生效：
MODULE LIST看输出里有没有bf
别用 Guava 或 .NET 内存版 BloomFilter<T>：多实例部署下各进程布隆状态不一致，爬虫绕过一个节点就全失效。
bfAdd 必须预热，且增量同步不能丢
布隆过滤器只对“已知合法 ID”有效，没预热等于白搭。常见错误是只在应用启动时查一次 DB 全量加载，之后新注册用户永远被拦。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 预热用批量 SQL：
SELECT id FROM users WHERE status = 1，避免分页查导致漏数据 - 写入用
BF.ADD user_filter {id}，别用BF.MADD批量——某些旧版 RedisBloom 对它支持不稳定 - 新增用户后，必须同步调一次
BF.ADD user_filter 123456，放在事务提交后、缓存写入前 - 删除用户时，布隆过滤器无法删除（本质不支持 remove），只能靠后续空值缓存兜底
bfExists 判断后必须严格分流，不能跳过空值缓存
BF.EXISTS 返回 false 表示“一定不存在”，可直接返回 404；但返回 true 只是“可能存在”，此时仍要走完整链路——查 Redis → 查 DB → 写缓存（含空值）。
- 错误写法：
if (!bfExists) return NotFound(); else return GetFromCacheOrDb();—— 这样漏掉了误判的那部分请求 - 正确顺序：
if (!bfExists) → 404；else if (cacheHit) → return；else if (dbHit) → cacheSet + return；else → cacheSet("NULL", 60s) + return - 空值必须用明确标记，比如
"EMPTY"字符串，而不是null或空格，避免和业务真实空响应混淆 - 空值 TTL 别设死 60，建议
60 + new Random().Next(0, 30)，防雪崩
误判率和容量要按实际 key 总量算，别抄默认值
误判率设成 0.001% 看着很美，但 1 亿用户下布隆位图要占近 1.2GB 内存，而 0.01%（1%）只要约 115MB，且实测拦截率超 99.7%。
- 公式：位数组长度
m ≈ -(n * ln(p)) / (ln(2)^2)，其中n是预计总 key 数，p是目标误判率 - 哈希函数个数
k ≈ (m/n) * ln(2)，通常取 3~7，RedisBloom 默认是 3 - 初始化命令：
BF.RESERVE user_filter 0.01 10000000（支持千万级，误判率 1%） - 如果 key 总量不确定，优先用缓存空对象 + 接口校验，布隆只作为第一层快筛
最易被忽略的是：布隆过滤器本身没有自动扩容机制，BF.RESERVE 定多少就是多少，超了会 silently 降级为更高误判率——上线前务必用线上预估量压测验证。
